[gmx-users] Question on checkpoint files and restarts/continuity
Mark.Abraham at anu.edu.au
Fri Apr 13 02:55:22 CEST 2012
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
> "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
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
> Thanks in advance for any help you can provide.
> J. Nathan Scott, Ph.D.
> Postdoctoral Fellow
> Department of Chemistry and Biochemistry
> Montana State University
More information about the gromacs.org_gmx-users