Appending after inital break

GROMACS version: 2020.7

I am having some difficulty with the default behavior of checkpointing.

I have a short run completed. I would like to restart the simulation from the checkpoint without appending to the first short run. This is straightforward, however it creates a “.part002” trajectory, and now it seems I will be unable to append in the future. I am forced to break my production run into .part002, .part003, etc" moving forward.

I would really prefer to keep the production run whole and appended. However I don’t see a simple way to do that without also including the first part. Is there any way to get gromacs to begin appending again after an initial break?

It’s often convenient to keep different names by creating separate .tpr files - say, eq.tpr and prod.tpr.

When you create prod.tpr after equilibration, make sure the .mdp does not generate velocities, and have your .cpt taken into account in gmx grompp by passing it as the -t parameter - this way positions and velocities will be read from the checkpoint.

Otherwise, you can just concatenate all the parts at the end, and trim the initial part in gmx trjconv or any analysis software with the -b parameter. It’s really just a question of what you find more convenient.

Yes, I’ve ended up feeding the checkpoint into grompp and then not using the checkpoint with mdrun, which lets me append as normal going forward. But I am a little confused about what happens when I do that. What exactly is the difference between giving the checkpoint to grompp vs giving it to mdrun, or doing both?

Unfortunately I have had issues with concatenating an trimming my trajectories due to floating point errors in the timestamps, at least on this version of GROMACS, so that hasn’t been an option for me.

As far as I know (and maybe someone will correct me there), there is little difference except for portability and continuation. Yet with a separate .tpr, your new run counts as starting from 0, which can have implications for a number of explicitly time-dependent algorithms (e.g. fast-growth or pull code). Of course if that’s not desirable, you can specify the initial part or timestep in the .mdp but then it gets redundant.

Time errors in the timestamps is something you can always fix, e.g. editing the time property of the trajectory in mdtraj, while with appending you’re at the risk of losing the whole simulation if anything with I/O breaks down big time (this almost doesn’t happen with more recent versions of Gromacs, but will still depend on how well maintained the cluster is).