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

[Mark Abraham]

Hi,

The simulation is 100% fine. Many of the tools (and their implementations)
date from earlier eras where so many time steps were simply impossible, and
some of what they do with handling time (as a floating-point number)
doesn't work well. Once you have about 7 significant digits in the time
stamp, then recomputing the time gap between frames requires a subtraction
that can no longer be accurate. The step numbers are 64-bit integers and
obviously one can infer the time from the knowledge of the intended output
period, but most tools aren't implemented to be able to read the .tpr and
trust that it was the one that produced the output in order to make such
deductions.

Running analysis tools from a double-precision build of GROMACS might
alleviate some symptoms, but I've never tried it.

> None of the GROMACS analysis codes run without error and the
simulation finishes without error

Is there a specific problem you are having?

Mark

On Wed, 19 Jun 2019 at 03:21, Eric R Beyerle <ebeyerle at uoregon.edu> wrote:

> 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
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>