This is I’m sure quite simple, but I haven’t figured it out yet. I have a simulation using a moving restraint using the colvars package. I am writing periodic restart files. When I restart the simulation from the binary restart file, I have to use the fix colvars command with a config file. I tried using the original config file that I started the simulation with, but that resets the position of the restraint to its initial value, rather than where it left off. What is the correct way to restart a colvars simulation so that the restraint starts from the correct restraint position?
Thanks for the help,
Seth
Hi @scmartin! When you load a LAMMPS restart file using read_restart, the Colvars state information will also be loaded, provided that you have already a consistent fix colvars line defined before reading the restart. This is the same as with other LAMMPS fixes, i.e. these should already been (re)defined in the LAMMPS before the read_restart command (link).
When you (re)define the Colvars fix, the restraint center should be the “original” one (and it will be printed as such). However, after reading the restart it should be updated to the correct value, which depends on the step number read from the restart.
Do you have enabled the keyword outputCenters? If so, it should be straightforward to check if this is the resulting behavior.
Please post your input if the behavior is indeed inconsistent with the documentation?
Giacomo
1 Like
Thank you for the response, Giacomo. Based on your response, I tried a couple of changes to the LAMMPS input file. I found that it only correctly set the restraint position if the fix command was immediately after the read_restart command. Originally I had the fix command after the neighbor, neigh_modify, kspace, and balace commands. When the fix command came after those, colvars set the restraint to the original value, rather than the value from the restart. When I moved the fix command to immediately after read_restart, it set the restraint to the correct value.
You should see from the log file whether a fix is properly restored or whether the restart info for the fix is discarded. Here is the relevant section of the read_restart documentation:
As indicated in the above list, the fixes used for a simulation are not stored in the restart file. This means the new input script should specify all fixes it will use. However, note that some fixes store an internal “state” which is written to the restart file. This allows the fix to continue on with its calculations in a restarted simulation. To re-enable such a fix, the fix command in the new input script must be of the same style and use the same fix-ID as was used in the input script that wrote the restart file.
If a match is found, LAMMPS prints a message indicating that the fix is being re-enabled. If no match is found before the first run or minimization is performed by the new script, the “state” information for the saved fix is discarded. At the time the discard occurs, LAMMPS will also print a list of fixes for which the information is being discarded. See the doc pages for individual fixes for info on which ones can be restarted in this manner. Note that fixes which are created internally by other LAMMPS commands (computes, fixes, etc) will have style names which are all-capitalized, and IDs which are generated internally.
Indeed, after checking the log with my fixes defined immediately after the read_restart command, the state data from my fixes are restored properly, but if the fixes are initialized after the commands I listed in my previous post, the fix info is discarded. I just found this in the documentation:
There are a handful of commands which can be used before or between runs which may require a system initialization. Examples include the “balance”, “displace_atoms”, “delete_atoms”, “set” (some options), and “velocity” (some options) commands. This is because they can migrate atoms to new processors. Thus they will also discard unused “state” information from fixes. You will know the discard has occurred because a list of discarded fixes will be printed to the screen and log file, as explained above. This means that if you wish to retain that info in a restarted run, you must re-specify the relevant fixes and computes (which create fixes) before those commands are used.
So the issue was certainly the balance command I was calling before the fix commands. Thanks to @giacomo.fiorin and @akohlmey for the guidance.