The simulation, which should run for a total of 65000000 steps, was interrupted, so I restarted from my binary restart file. It starts successfully at step 27130000, but it sets the restraint at a value of 30.5. The output from colvars in the LAMMPS log file confirms that the initial step number from the restart is 27130000.
Based on the output of my colvars trajectory file from before the interruption and double checked by a quick calculation, I believe the moving restraint should be initializing at 27.25 at step 27130000. The restraint shouldn’t move to 30.5 until step 30000001 if I am understanding how moving restraints are supposed to work correctly. If this is indeed an error in how the colvar is being initialized, I will submit it as an issue to the colvars Github page, but I wanted to see if I was misunderstanding how it should work first based on this communities knowledge pool.
It looks like this bugfix may be relevant to your use case. It is included in a later version of the Colvars library than the one you have, and is also currently submitted for potential inclusion in the LAMMPS main repository.
I don’t know whether it would be more laborious for you to continue this simulation vs. running a new one with the new version. In any case, I would appreciate if you could post your simulation files (to the extent that you can share) in a GitHub issue on Colvars to confirm that the behavior you are seeing was already fixed.
Thank you for the reply, that bug fix does look like it will probably address the issue I’m seeing. Unfortunately I’m unable to share the simulation files in this particular case. For this bug, is it simply a matter of an offset in the step number that colvars is using to calculate the position of the restraint, but correct sampling for the values of the restraint reported in the colvars trajectory file? If that’s the case, I can still use the data from the restarted simulation for my analysis and perhaps just run another simulation for some further sampling for the restraint positions that weren’t fully sampled.
Correct, the restraint center is not what you would expect due to the bug in restarting, but once the center is set the forces are computed consistently, and the center will keep moving toward the targets as intended.
Indeed I would totally recommend running additional simulations to cover the gap. A good idea would be to run a simulation where the restraint moves backward toward the original center.
Most umbrella-sampling simulations nowadays are also carried out with independent windows running in parallel, after having been initialized as close as possible to equilibrium.