While I've read the cautions in the User Manual about the half-step offset between the coordinates and velocities when using leap-frog based integrators when calculating energies, a point of confusion for me is how to properly handle restarting simulations. If I'm saving coordinates and velocities using calls to state.getPositions() and state.getVelocities() and saving them to some file as numpy arrays (then serializing them in someway, whether it be using pickles or npy files), should I be synchronizing the velocity by giving it a half timestep kick before I pushing the coordinates and velocities using context.setPositions() and context.setVelocities()?
Looking at Robert's code in https://github.com/rmcgibbo/openmm-cmd, the restart files it is writing do the half-kick when using leap-frog based integrators. However, digging through the OpenMM restart reporters in https://github.com/swails/ParmEd, I can't find equivalent code. I tried to look for similar coord/veloc sync'ing in the openmm checkpoint files, but I didn't see anything (although I'm not sure I fully traced through all relevant code).
I was hoping someone could clarify the correct way of restarting a simulation when dealing with openmm at the low level of setPositions/setVelocities. It might also be helpful to codify this in the documentation. Any assistance would be appreciated.
Josh
Restarting OpenMM simulations
-
Peter Eastman
- Posts: 2602
- Joined: Thu Aug 09, 2007 1:25 pm
Re: Restarting OpenMM simulations
Hi Josh,
There's no need to do that. The positions and velocities reflect the current state of the integrator, whatever type of integrator that happens to be. So if you save them then load them up again, they'll still be correct (as long as you're using the same integrator).
On the other hand, if you change integrators they would not be correct. If you save velocities from a leapfrog integrator then load them into a velocity Verlet integrator, you need to apply the half step correction. Likewise, if you change the time step then they'll no longer be offset by the correct amount. I believe that's why Robert used the convention in his code of always saving on-step velocities. That way he's free to change the integrator, and just do the appropriate adjustment before saving and after loading for whatever integrator is being used at that point.
Peter
There's no need to do that. The positions and velocities reflect the current state of the integrator, whatever type of integrator that happens to be. So if you save them then load them up again, they'll still be correct (as long as you're using the same integrator).
On the other hand, if you change integrators they would not be correct. If you save velocities from a leapfrog integrator then load them into a velocity Verlet integrator, you need to apply the half step correction. Likewise, if you change the time step then they'll no longer be offset by the correct amount. I believe that's why Robert used the convention in his code of always saving on-step velocities. That way he's free to change the integrator, and just do the appropriate adjustment before saving and after loading for whatever integrator is being used at that point.
Peter