Eneconv -dt and gmx energy: Data Points Not Skipped Properly

User discussions
1

GROMACS version: 2023
GROMACS modification: No

I want to extract the pressure tensor with a larger timestep than the one saved in the *.edr file. Currently, I am saving data every 2 fs, but I want to reduce the data so that it is saved every 100 fs in the new *.edr file. To achieve this, I first run:

gmx eneconv -f original_energy.edr -o new_energy.edr -dt 0.1

Then, I use the gmx energy command to extract the pressure tensor elements. However, the resulting file starts with the correct timestep but eventually reverts to the original timestep. This “falling back” happens gradually, initially affecting only some points, but eventually, all of them revert to the original timestep.

Here is an excerpt from the output:

0.000000  2902.700928  -23.706738  -25.974232  2882.134033  -19.827463  2929.415039
    0.100000  2933.126221    1.402500  -22.858887  2926.376953  -10.488109  2946.551270
    0.200000  2980.487305    8.712797   -2.398444  2866.177734   10.947755  2933.248535
...
7895.300000  2957.071289    8.274111  -38.966511  2946.506348  -10.758986  2924.870605
 7895.302000  2957.775635    7.972142  -39.881687  2946.856934  -10.290474  2923.739014
 7895.400000  2961.532715  -13.395555    4.138320  2930.099854  -20.582762  2952.523193
 7895.402000  2961.086670  -13.742041    4.967726  2930.944092  -20.398476  2953.222168
...
196541.820000  2950.814209  -34.054672   16.960943  3000.986328  -41.621239  2961.092773
196541.822000  2948.037109  -34.090576   17.729280  3000.609863  -41.881737  2962.319580
196541.824000  2945.478271  -33.982197   18.435038  3000.094727  -41.861515  2963.336670
196541.826000  2943.116211  -33.752594   19.292294  2999.329590  -41.678364  2964.063477
196541.828000  2940.767822  -33.396626   20.339138  2998.497314  -41.463585  2964.732422
196541.830000  2938.362305  -32.808075   21.320389  2997.603760  -41.217400  2965.726318

I tried on different clusters, different GROMACS versions, using the -e and -b flag… nothing worked so far.

2

If you do gmx check -e new_energy.edr what is the terminal output? What was the terminal output of your gmx eneconv command?

3

The gmx check outputs no issues until 7895.2, and then it starts failing:

Reading energy frame  78000 time 7800.000         
Timesteps at t=7895.2 don't match (0.100098, 0.00180469)

Timesteps at t=7895.2 don't match (0.00195312, 0.0978516)

Timesteps at t=7895.3 don't match (0.0976562, 0.00219531)

and the gmx eneconv command provides the following output:

Reading energy frame      0 time    0.000         
Continue writing frames from t=0, step=0
Reading energy frame 100000000 time 200000.000         riting frame time 199999    
Last frame written was at step 100000001, time 200000.002000
Wrote 47702668 frames
4

Your energy file must be huge. Perhaps eneconv can’t handle that many frames. It might be worth trying a more reasonable (according to me) -dt 10 or even -dt 100? I don’t think that would work either, but it’s worth a try. I guess this might be a bug in GROMACS, but the problem is that it’s difficult to reproduce, since the files cannot easily be distributed. Could you open an issue at Issues · GROMACS / GROMACS · GitLab?

By the way, why are you saving energies every step? Calculating energies that often will take a lot of time and you don’t have any use for it (as far as I understand). I think the recommended nstenergy = 1000 is unnecessarily low, especially if you are running simulations more than a nanosecond.

5

Sure, I will make some tests in case that memory is the problem and then I’ll open the issue.

To answer your question, I made the original simulation storing the energy at every step and from there I tested how increasing the step size impacts the Green Kubo integral (viscosity in this case). It seems like I need very fine detail for my system. It is slow but doable, and it is worth a try.