Checkpointing
Overview¶
Checkpointing is the process of saving the current state of a running job at regular intervals so that it can be resumed later from that state, rather than starting from scratch. This is especially useful in long-running or resource-intensive tasks on HPC systems like Wulver, where interruptions or failures may occur.
Checkpointing typically involves:
- Periodic saving of application state (memory, variables, file handles, etc.)
- Resuming computation from the last saved state
- Integration with SLURM job re-submission or recovery workflows
Why Use Checkpointing?¶
| Benefit | Description |
|---|---|
| Failure Recovery | Resume jobs from the last checkpoint after a node crash or time expiration. |
| Efficient Resource Use | Prevents waste of computation time on long jobs that are interrupted. |
| Preemption Tolerance | Helps tolerate job preemption on shared clusters or spot instances. |
| Job Time Limit Bypass | Breaks large jobs into smaller chunks to fit within SLURM time limits. |
Examples for checkpointing¶
Save intermediate state using Python’s built-in pickle module — ideal for lightweight scripts.
A common practice in PyTorch to checkpoint model weights, optimizer state, and epoch index — useful for training recovery.
Using Keras callbacks, checkpoints are saved automatically during training. Only model weights are saved to keep storage efficient.
In C/C++, you can implement basic checkpointing by writing a loop index or state to a file and loading it at the next run. Ideal for simple simulations or compute-intensive loops.
GROMACS supports checkpointing with .cpt files during molecular simulations:
LAMMPS checkpointing is usually done using write_restart and read_restart: