Hi!
first of all, thank you for maintaining this amazing plugin. I've encountered a problem when running metadynamics with openmm-plumed. The core of the program is the following:
A Gaussian is placed every 100 steps in the protocol
Integration for 100 steps is performed, the system is in configuration x1
The positions in the context are set to another configuration, lets say x2
The energy of that configuration x2 is evaluated
The simulation is reset to the configuration x1
Repeat the process
Strangely, plumed updates the HILLS file based on x2, not on x1. But an energy evaluation should not be counted as a step, am I right? Shouldn't this be prevented from happening by this check?
Here is a small example of a simulation script for an Na+Cl- ion pair together with the resulting (wrong) HILLS file: metad_test.zip. A workaround is to set the system's StepCount to something that is not a multiple of the bias deposition stride, and set it back after the calculation.
Thanks for your help!
Edit:
Could it be linked to the way openmm increments the step counter, essentially doing:
step=0
CalculateForces()
step+= 1
...
So that here the step counter is 100 after one round of the above protocol, but the force calculation was last performed when the step counter was 99, therefore the energy request triggers the update?
Hi! first of all, thank you for maintaining this amazing plugin. I've encountered a problem when running metadynamics with openmm-plumed. The core of the program is the following:
Strangely, plumed updates the HILLS file based on x2, not on x1. But an energy evaluation should not be counted as a step, am I right? Shouldn't this be prevented from happening by this check?
Here is a small example of a simulation script for an Na+Cl- ion pair together with the resulting (wrong) HILLS file: metad_test.zip. A workaround is to set the system's StepCount to something that is not a multiple of the bias deposition stride, and set it back after the calculation.
Thanks for your help!
Edit: Could it be linked to the way openmm increments the step counter, essentially doing: step=0 CalculateForces() step+= 1 ... So that here the step counter is 100 after one round of the above protocol, but the force calculation was last performed when the step counter was 99, therefore the energy request triggers the update?