[gmx-users] GROMACS Output Timestep Changes Over a Long, Check-pointed Simulation

[Eric R Beyerle]

Hi,

I've run a fairly long (1 microsecond) trajectory of ubiquitin in spc/e 
on a supercomputer that allows a 48-hour runtime on their nodes. Since 
the simulation doesn't finish in 48 hours, I used the checkpoint files 
from the simulation to restart the simulation, using the following mdrun 
command:

protname="1UBQ"

ibrun gmx_mpi mdrun -v -s ${protname}_pro.tpr -e ${protname}_pro.edr -o 
${protname}_pro.trr -x ${protname}_pro.xtc -c ${protname}_pro_end.gro -g 
${protname}_pro.log -cpo state_pro.cpt -cpi state_pro.cpt -append 
-nsteps 500000000

I've noticed that after ~10 ns of simulation time that the desired write 
frequency to the .xtc file (every 0.2 ps) slowly drifts up and down 
until, after about 500 ns of simulation time, I get the following output 
when running gmx check on the .xtc file:

...

Timesteps at t=527218 don't match (0.1875, 0.25)

Timesteps at t=527219 don't match (0.25, 0.1875)

Timesteps at t=527219 don't match (0.1875, 0.25)

Timesteps at t=527220 don't match (0.25, 0.1875)

Timesteps at t=527220 don't match (0.1875, 0.25)

Timesteps at t=527221 don't match (0.25, 0.1875)

Timesteps at t=527221 don't match (0.1875, 0.25)

Timesteps at t=527222 don't match (0.25, 0.1875)

Timesteps at t=527222 don't match (0.1875, 0.25)

...

In short, it looks to me as though there is a slow drift away form the 
desired 0.2 ps write frequency to file before GROMACS begins to 
oscillate between timesteps of 0.875 and 0.25 ps.

Is this effect caused by restarting from the .cpt file? Would running 
shorter simulations and concatenating them together alleviate this 
problem? None of the GROMACS analysis codes run without error and the 
simulation finishes without error -- is the trajectory trustworthy and 
just the timestamps are incorrect or does the entire last half of the 
simulation need to be thrown away?

Thanks,

Eric Beyerle