How to Restart or Extend a GROMACS MD Simulation After a Crash or Timeout

To continue a crashed or timed-out GROMACS run, restart it from its checkpoint with gmx mdrun -s topol.tpr -cpi state.cpt; the run resumes exactly where it stopped. To lengthen a run that finished too short, first add time with gmx convert-tpr -extend, then restart from the checkpoint the same way.

A long molecular dynamics run rarely dies because your science was wrong. It dies because Google Colab cut you off at its runtime limit, a shared HPC queue hit its walltime, or your laptop went to sleep. Beginners then assume the whole simulation is lost and start over, throwing away days of compute. It is not lost. GROMACS writes a checkpoint file as it runs, and that file lets you pick up an interrupted run or push a finished one further, with two commands. This guide from the StemSkills Lab team, who have spent 10+ years running production MD, shows you both, plus how to prove the result is one clean trajectory and how to dodge the errors that trip students up. If GROMACS itself is still new to you, start with our GROMACS molecular dynamics guide and come back here when a run breaks.

What does it mean to restart versus extend a GROMACS simulation?

These are two different problems that share one tool, the checkpoint file, so it helps to name them clearly:

• Restart (continue): your gmx mdrun was interrupted before it reached the number of steps set in the .tpr. You want to finish the run you already defined.
• Extend: your run reached its planned end, but the trajectory is too short to answer your question (the protein has not equilibrated, a binding event has not happened). You want to add more time on top of a completed run.

A restart needs nothing but the checkpoint. An extend needs a new run input file first, because the original .tpr already knows it is finished. GROMACS is the free, open-source MD engine described in Abraham et al., “GROMACS: High performance molecular simulations through multi-level parallelism from laptops to supercomputers,” SoftwareX 1-2 (2015): 19-25 (doi:10.1016/j.softx.2015.06.001), and both operations are core features, not workarounds.

How do you continue a GROMACS run that crashed or hit a walltime?

Point gmx mdrun at the same run input file and the checkpoint it left behind:

gmx mdrun -s topol.tpr -cpi state.cpt

That is the whole restart. The -cpi (checkpoint in) flag reads state.cpt, restores the exact positions, velocities, box, and step counter, and continues until the step count in topol.tpr is reached. By default GROMACS appends the new frames to your existing .xtc, .edr, and .log files, so you end with a single set of output files, as if the run had never stopped.

On an HPC queue with a walltime, combine the restart with -maxh, which tells mdrun the maximum number of hours to run so it stops cleanly and writes a final checkpoint before the scheduler kills the job:

gmx mdrun -s topol.tpr -cpi state.cpt -maxh 23.5

Submit that same line again for each queue slot. Each job continues from the last checkpoint, and appending keeps everything in one trajectory. This is the standard pattern for running a 500 ns simulation across many 24-hour queue windows.

How often does GROMACS write a checkpoint file?

By default GROMACS writes a checkpoint every 15 minutes of wall-clock time. The gmx mdrun documentation labels this the “Checkpoint interval (minutes)” and sets the -cpt default to 15, so at worst a crash costs you the last quarter-hour of compute, not the whole run. You can shorten it on a flaky machine:

gmx mdrun -s topol.tpr -cpt 5

Two details matter for safety. First, the checkpoint output file is state.cpt (the -cpo flag), and GROMACS keeps the previous one as state_prev.cpt, so a machine that dies mid-write does not leave you with a corrupt checkpoint and nothing else. Second, appending is designed to be exact. The GROMACS documentation states plainly that “the result with appending will be the same as from a single run,” which is why a well-managed restart chain is scientifically identical to one uninterrupted run. You can read the full behaviour in the official gmx mdrun reference and the managing long simulations guide.

How do you extend a GROMACS run that finished too short?

The original .tpr has reached its final step, so mdrun will refuse to add more time to it. You first build a new run input file that asks for more, using gmx convert-tpr. To add 10 ns (10000 ps) on top of the finished run:

gmx convert-tpr -s topol.tpr -extend 10000 -o next.tpr
gmx mdrun -s next.tpr -cpi state.cpt

The -extend option, documented as “Extend runtime by this amount (ps),” lengthens the run relative to its current end. If you instead want the total simulation to reach a specific time, use -until (“Extend runtime until this ending time (ps)”). To take a run out to a total of 100 ns:

gmx convert-tpr -s topol.tpr -until 100000 -o next.tpr
gmx mdrun -s next.tpr -cpi state.cpt

There is also -nsteps, which changes the number of steps directly rather than a time in ps. Whichever you pick, the pattern is the same: convert the old .tpr into a longer next.tpr, then start mdrun on the new file while feeding it the checkpoint from the completed run so it continues from the last frame instead of from t = 0.

Should you use append or -noappend?

When you continue from a checkpoint, GROMACS appends to your existing output files by default. That is almost always what you want, because it produces one continuous trajectory with no extra bookkeeping. The alternative, -noappend, writes a fresh set of numbered files for each continuation instead:

Use append unless GROMACS complains that it cannot append safely. If your original output files are gone or were renamed, -noappend lets the run continue by opening new part files, and you join them afterwards.

How do you confirm the continuation is one continuous trajectory?

Never assume the restart worked, check it. gmx check reports the number of frames and the time step of a trajectory:

gmx check -f traj_comp.xtc

Read the reported frame count and last time. They should match the longer run you asked for, with an even spacing and no gap where the crash happened. If you used -noappend and have several part files, join them with gmx trjcat, which drops the overlapping frame at each restart boundary so you do not double-count:

gmx trjcat -f traj_comp.part0001.xtc traj_comp.part0002.xtc -o md_full.xtc

Then run gmx check on md_full.xtc to confirm the stitched trajectory is continuous before you compute RMSD or any other analysis. Getting this verification habit early is one of the skills we sequence in the computational biology skills roadmap.

What errors trip students up when restarting GROMACS?

Four failures account for most lost time. Here is what each looks like and how to fix it.

• Missing or deleted checkpoint. If state.cpt is not there, mdrun does not warn you loudly; it assumes a normal run and starts appending from t = 0, quietly overwriting your progress. Fix: confirm state.cpt exists before you resubmit, and never delete it during a run. The backup state_prev.cpt is your safety net if the newest checkpoint is corrupt.
• Mismatched .tpr. Feeding a checkpoint from one system into an unrelated .tpr throws a fatal error because the checkpoint stores checksums of the run. Fix: when extending, always generate next.tpr from the same original .tpr with convert-tpr, and do not hand-edit run input files.
• Duplicated frames. If you use -noappend and then naively concatenate the part files, you can double the frame that sits at the restart boundary. Fix: prefer append, or join with gmx trjcat, which removes the overlap for you.
• Append refused after moving files. Appending verifies file integrity with stored checksums, so if you renamed or truncated an output file, GROMACS refuses to append. Fix: keep the original output files in place, or restart that continuation with -noappend.

Frequently asked questions

Is a restarted GROMACS simulation scientifically valid?

Yes. A restart from a checkpoint restores the full state, including velocities and the random seed state, so appending gives the same result as one continuous run. That guarantee is why long simulations are routinely split across many queue jobs.

Can I continue a run if I only have the .tpr and not the checkpoint?

Not as a continuation. Without state.cpt you can only start the run again from the beginning. If you have an intermediate trajectory or a .gro snapshot you can build a new starting structure from it, but that is a new run, not a true continuation.

What is the difference between -extend and -until?

-extend adds a given amount of time in ps on top of the current end of the run. -until sets the total end time in ps, so the added amount depends on how far the run already reached. Use whichever number you have in hand.

How do I make GROMACS stop before an HPC walltime instead of being killed?

Add -maxh with the number of hours slightly below your queue limit, for example -maxh 23.5 in a 24-hour slot. GROMACS finishes the current step, writes a checkpoint, and exits cleanly so the next job can continue.

Does -noappend lose any data compared with appending?

No. It writes the same frames into separate numbered files instead of one. You get identical data once you concatenate the parts with gmx trjcat; the only cost is the extra stitching step.