[gmx-users] Question on checkpoint files and restarts/continuity

[Mark Abraham]

On 13/04/2012 2:36 AM, J. Nathan Scott wrote:
> Hi all,
>
> I had a very quick question I couldn't find an exact answer for that
> I'm sure someone here can answer very easily. The Gromacs website says
> (http://www.gromacs.org/Documentation/File_Formats/Checkpoint_File):
>
> "A .cpt file is produced by mdrun at specified intervals (mdrun -cpt),
> and contains information on all the state variables in a simulated
> system.  In the case of a crash (hardware failure, power outage, etc),
> a checkpoint file can be used to resume the simulation exactly as it
> was before the failure.  Simulations can also be extended using a
> checkpoint file.
>
> During the course of a normal mdrun process (provided that it runs for
> longer than one -cpt interval), two checkpoint files will be written,
> state.cpt and state_prev.cpt.  When extending simulations, use
> state.cpt; the state_prev.cpt is a backup copy of the previous
> checkpoint, maintained in case something goes wrong at the current
> checkpoint.  To convince yourself of this fact, you can inspect the
> contents of a checkpoint file with gmxcheck."
>
> My question is, does the checkpoint file have to contain positions,
> velocities, *and* forces to preserve continuity? If forces are *not*
> included in the checkpoint file, would that mean that they'd be
> recalculated based on positions when the simulation resumes, thereby
> creating a (slight) discontinuity in the trajectory?

Forces are used to calculate updates to velocities and positions. 
There'd be no reason to store the forces for a restart if you've done 
the update, and that's how the checkpoint works. You'll see in a gmxdump 
of a .cpt that there is no force vector. As such, there cannot be a 
discontinuity other than the length of walltime between the update and 
the calculation of new forces. :-P See Fig 3.3. of the GROMACS manual. 
Checkpoint is part of step 4.

>
> On a closely related topic, some colleagues are attempting to use an
> existing trajectory to start new simulations ("branching" points if
> you will). I have advised them that using grompp's -time option, the
> .trr file, and the .edr file for the existing trajectory to generate
> new .tpr files is probably the way to go, since positions and
> velocities will be read from the .trr file (their .trr file does not
> contain any force information)

... which isn't read anyway.

>   and the information from the .edr file
> will preserve system equilibration via the coupling constants. They
> actually *want* these simulations to diverge. Have I misunderstood
> anything about the way these files are used/work? Does this seem like
> a reasonable procedure or is there a preferred method for doing
> something like this?

These restarts are (in principle) non-divergent. In practice, they will 
slowly diverge for the kinds of reasons discussed here 
http://www.gromacs.org/Documentation/Terminology/Reproducibility. Faster 
diverging is possible if you re-generate velocities (don't know how this 
interacts with grompp -time, but there are various obvious solutions if 
it doesn't work - gmxcheck is your friend here), but then you have to 
re-equilibrate.

Mark

>
> Thanks in advance for any help you can provide.
>
> --
> ----------
> J. Nathan Scott, Ph.D.
> Postdoctoral Fellow
> Department of Chemistry and Biochemistry
> Montana State University