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
--
gmx-users mailing listgmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
