Does gmx filter only smooth positions or does it also affect velocities? Thanks!
I think it just filters positions, and from a quick look at the code it seems that it does not even output velocities.
Yup, we saw that all the velocities were gone and wondered if there was a switch somewhere. This may be the easiest feature request ever…
Why would you want to filter velocities? There are rather meaningless with a smoothed trajectory.
Very meaningful if I want to create a 3D map/contour of electroosmotic solvent flow through a nanopore, averaged over a microsecond-long simulation.
Then you would need very frequent velocity output to have somewhat correlated velocities. It is nearly trivial to add velocities to gmx filter. I can do that if that is of use.
If you could do this and then maybe drop a note here when it becomes available, it would be very much appreciated.
Agreed on the need to drop velocities frequently. We are at something like 5 ps and the intention is to make it even more frequent as soon as our admins realize that a 200Gb quota per user is a joke.
I added velocity output and also cleaned up the code a bit. Could you try this? I think you should be able to only copy the gmx_filter.cpp file to a relatively recent distribution of GROMACS, if you don’t want to download the main branch.
I will do my best to try within a few weeks. We were able to get somewhat decent flow maps without any filtering, simply on the basis of many frames to average from, but we can’t store those trajectories for long, so part of the goal here is to create filtered trajectories to store for good. Thanks a lot for your help.
We incorporated this code into the 2026-rc version and built it. Something strange is going on: for some reason, there is artificial water drift toward upper right corner of the box. Our box is nearly cubic, so it’s basically at 45 degree angle in the XZ-plane. The filter was used with -nf 10 -nojump no. Could be aliasing, but this would be the weirdest kind of aliasing I’ve ever seen, and I’ve done a lot of dsp in the past…
upd: upon visually inspecting this filtered trajectory, the entire water population is flying upwards. I tried filtering with -nojump yes and now the gmx filter process hangs while the filtered output is an empty file. The simulation itself seems fine, it’s only the filter.
I found and fixed an issue with the clearing of the filtered frames. I suppose that is causing this.
Thanks! Is the updated code at the link you provided above?
Yes .
I think the utility may be destroyed at this point. Here are the starting and final frames for OW and also my commands to get this trajectory (I’m pretty sure you could reproduce this by running bulk water).
gmx filter -f traj.trr -s run.tpr -ol filtered.trr -nf 10 -nojump no
gmx trjconv -f filtered.trr -s run.tpr -n index.ndx -o water_filtered.gro
2SOL OW 1-446236459881354756096.000 0.008-446236635803215200256.000 0.0004 -0.0004 -0.0002
3SOL OW 2-361184221699858497536.000 0.010-361184221699858497536.000 -0.0021 0.0001 -0.0007
4SOL OW 3-446237832071866220544.000 0.006-446238007993726664704.000 0.0003 0.0005 -0.0003
5SOL OW 4-361188338271392890880.000 0.000-361188338271392890880.000 -0.0002 0.0010 0.0001
6SOL OW 5-446239204262377684992.000 0.006-446239380184238129152.000 0.0005 0.0023 0.0007
7SOL OW 6-361192454842927284224.000 0.003-361192454842927284224.000 -0.0002 0.0001 0.0022
8SOL OW 7-446240576452889149440.000 0.013-446240752374749593600.000 0.0003 -0.0006 0.0001
9SOL OW 8-361196606598833766400.000 0.003-361196606598833766400.000 -0.0005 -0.0015 -0.0004
10SOL OW 9-446241983827772702720.000 0.007-446242124565261058048.000 -0.0006 -0.0001 -0.0004
11SOL OW 10-361200723170368159744.000 0.006-361200723170368159744.000 0.0011 -0.0018 -0.0013
12SOL OW 11-446243356018284167168.000 0.006-446243531940144611328.000 -0.0001 -0.0012 0.0000
13SOL OW 12-361204839741902553088.000 0.010-361204839741902553088.000 -0.0006 -0.0012 -0.0005
14SOL OW 13-446244728208795631616.000 0.015-446244904130656075776.000 0.0013 0.0004 0.0010
15SOL OW 14-361208991497809035264.000 0.002-361208991497809035264.000 0.0003 0.0018 0.0001
16SOL OW 15-446246100399307096064.000 0.007-446246276321167540224.000 0.0014 -0.0001 -0.0001
17SOL OW 16-361213108069343428608.000 0.002-361213108069343428608.000 -0.0003 0.0007 -0.0012
18SOL OW 17-446247472589818560512.000 0.011-446247648511679004672.000 0.0013 -0.0013 -0.0000
19SOL OW 18-361217224640877821952.000 0.011-361217224640877821952.000 -0.0000 -0.0003 -0.0007
20SOL OW 19-446248844780330024960.000 0.013-446249020702190469120.000 -0.0007 0.0007 -0.0003
21SOL OW 20-361221376396784304128.000 0.004-361221376396784304128.000 0.0017 -0.0012 0.0015
There were two, rather trivial, bugs. I fixed those now. Available at the link. I checked that the code does not produce nonsense output, but I haven’t actually visualized the trajectory.
I think we are in business, thank you very much. Quick question: what are the velocity units here? I am assuming that because gro format has positions in ns and time is typically in ps, the velocity would be km/s. Is that correct?
The MD units are nm and ps, so it’s nm/ps. But you can use km/s, if you prefer.
A normal person not traumatized by MD units would use m/s, but you and I seem to be on the same page regardless. ;)
Just to quickly update, thanks a lot for the effort, I really do appreciate it. Trying to filter velocities while keeping output frequency such that we do not end up with terabytes of raw trajectories proved to be completely hopeless due to crazy amounts of aliasing.