Restarting simulation from .xml file yields wrong timestamp on Plumed output

[mdpoleto]

Hi,

I ran a metadynamics simulation on strides of 100ns each using OpenMM v7.5.1 + Plumed v2.7. Although I can successfully restart my simulation and Plumed continues outputting data as it should, the timestamp used seems to be incorrect.

I am restarting my simulation using the .xml state file outputted at 800ns. I am explicitly defining the correct "simulation.currentStep" and current time ("simulation.context.setTime()") before actually triggering the "simulation.step(nsteps)" command but Plumed still outputs a timestamp starting from 0.

Below there is a set of input files that should yield the error. This error only appears when I restart my simulation from the .xml state file. Loading from the checkpoint works just fine.

restart_timestamp.zip

Any ideas on this is highly appreciated.
Thanks!

[raimis]

OpenMM states files doesn't store the number of steps, just a simulation time. I guess, the rational is that OpenMM have variable-timestep integrators. So, when you restart a simulation from a XML file the new context starts counting steps from zero. Meanwhile, the checkpoint preserves entire context data. Probably @peastman can comment more on this.

On the other side, PLUMED assumes a fixed time step (

openmm-plumed/platforms/cuda/src/CudaPlumedKernels.cpp

Line 155 in 5406068

plumed_cmd(plumedmain, "setTimestep", &dt);

) and require to pass the number of steps (

openmm-plumed/platforms/cuda/src/CudaPlumedKernels.cpp

Line 225 in 5406068

plumed_cmd(plumedmain, "setStep", &step);

).

This might be solved with the next release (openmm/openmm#2655, openmm/openmm#3191), but apart the wrong step count, PLUMED should work correctly after these restarts.

[peastman]

I don't have any good solution for the current version. Having States record the step count should provide a straightforward solution. That's tentatively planned for inclusion in the next release.

[mdpoleto]

Thank you both for the clarification. I am not sure if this is a Plumed or a OpenMM-Plumed plugin kind of modification but I wonder if Plumed could re-read the current step number (or the simulation time) as defined by OpenMM the same way it reads the current atomic position. That way users can define the correct "simulation.currentStep" and current time ("simulation.context.setTime()") in the OpenMM script when restarting a simulation.

[raimis]

After openmm/openmm#3248 is merged and released, we can solve this issues.