CheckpointReporter

class openmm.app.checkpointreporter.CheckpointReporter(file, reportInterval, writeState=False)

CheckpointReporter saves periodic checkpoints of a simulation. The checkpoints will overwrite one another – only the last checkpoint will be saved in the file. Optionally you can saved serialized State objects instead of checkpoints. This is a more portable but less thorough way of recording the state of a simulation.

To use it, create a CheckpointReporter, then add it to the Simulation’s list of reporters. To load a checkpoint file and continue a simulation, use the following recipe:

>>> simulation.loadCheckpoint('checkpoint.chk')

Reloading a saved State can be done like this:

>>> simulation.loadState('state.xml')

Notes: A checkpoint contains not only publicly visible data such as the particle positions and velocities, but also internal data such as the states of random number generators. Ideally, loading a checkpoint should restore the Context to an identical state to when it was written, such that continuing the simulation will produce an identical trajectory. This is not strictly guaranteed to be true, however, and should not be relied on. For most purposes, however, the internal state should be close enough to be reasonably considered equivalent.

A checkpoint contains data that is highly specific to the Context from which it was created. It depends on the details of the System, the Platform being used, and the hardware and software of the computer it was created on. If you try to load it on a computer with different hardware, or for a System that is different in any way, loading is likely to fail. Checkpoints created with different versions of OpenMM are also often incompatible. If a checkpoint cannot be loaded, that is signaled by throwing an exception.

In contrast, a State contains only the publicly visible data: positions, velocities, global parameters, box vectors, etc. This makes it much more portable. Reloading the State will put the Simulation back into approximately the same state it had before, but you should not expect it to produce an identical trajectory to the original Simulation.

__init__(file, reportInterval, writeState=False)

Create a CheckpointReporter.

Parameters

• file (string or open file object) – The file to write to. Any current contents will be overwritten. If this is a file object, it should have been opened in binary mode if writeState is false, or in text mode if writeState is true.

• reportInterval (int) – The interval (in time steps) at which to write checkpoints.

• writeState (bool=False) – If true, write serialized State objects. If false, write checkpoints.

Methods

__init__(file, reportInterval[, writeState])	Create a CheckpointReporter.
describeNextReport(simulation)	Get information about the next report this object will generate.
report(simulation, state)	Generate a report.

describeNextReport(simulation)

Get information about the next report this object will generate.

Parameters

simulation (Simulation) – The Simulation to generate a report for

Returns

A five element tuple. The first element is the number of steps until the next report. The remaining elements specify whether that report will require positions, velocities, forces, and energies respectively.

Return type

tuple

report(simulation, state)

Generate a report.

Parameters

• simulation (Simulation) – The Simulation to generate a report for

• state (State) – The current state of the simulation