Equilibration/annealing

[ppxasjsm]

In the original version with integrate also doing a minimization/annealing, this process was called equilibration. Question: Should there be an annealing option, as well as an equilibration option? To me an annealing would be slowly pushing the system to the right value of lambda. An equilibration would be a couple of picoseconds dynamics, already at the correct value of lambda, before starting any measurements.

At the moment equilibration iterations are annealing steps. I would propose the following parameters: `` minimization_tol.val #tolerance for minimization minimization_maxiter.val #maximum number of iterations anneal_steps.val #number of steps for each round of annealing anneal_timesteps.val #timestep for the annealing equil_steps.val #number of actual equilibration steps equil_timestep.val #time step of the equilibration

`` The annealing of course only makes sense if there is something to be annealed (i.e. in a free energy simulation.)

[jmichel80]

Yes these are two separate operations we want to be able to perform independently.

Also we could always do annealing with discrete jumps of lambda in python, then calling equilibrate() for nsteps at a given lambda value. Overheads for context creation are likely reasonable if doing several steps of MD.

So yes i vote for annealing = slow continuous change of lambda from an initial value to a target value done with a single API call and a single openmm context creation.

---

Julien Sent from my phone. On 5 May 2015 17:58, "ppxasjsm" notifications@github.com wrote:

In the original version with integrate also doing a minimization/annealing, this process was called equilibration. Question: Should there be an annealing option, as well as an equilibration option? To me an annealing would be slowly pushing the system to the right value of lambda. An equilibration would be a couple of picoseconds dynamics, already at the correct value of lambda, before starting any measurements.

At the moment equilibration iterations are annealing steps. I would propose the following parameters: `` minimization_tol.val #tolerance for minimization minimization_maxiter.val #maximum number of iterations anneal_steps.val #number of steps for each round of annealing anneal_timesteps.val #timestep for the annealing equil_steps.val #number of actual equilibration steps equil_timestep.val #time step of the equilibration

`` The annealing of course only makes sense if there is something to be annealed (i.e. in a free energy simulation.)

— Reply to this email directly or view it on GitHub https://github.com/michellab/Sire/issues/6.

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

[jmichel80]

I think I have discovered why we all have been struggling with a number of simulations crashing immediately after equilibration with a typical "NaN or Inf has been generated along the simulation" message when turning on the minimization protocol implemented by Gaetano.

The problem is that the OpenMM minimizer is basically a wrapper to a third party L-BFGS algorithm. However OpenMM also checks that constraints can still be satisfied after an iteration of minimization. The code tries various things but essentially gives up if the constraints are too badly violated. If you want to know all the gory details check void LocalEnergyMinimizer::minimize(Context& context, double tolerance, int maxIterations) in OpenMM-6.2.0-Source/openmmapi/src/LocalEnergyMinimizer.cpp

Constraints can be violated if for instance the coordinates to minimize have bad steric clashes. We usually did not have this problem, but it is now happening more frequently since FESetup has been changed to produce boxes that have consistent sizes for mappings A-->B and B-->A, at the expense of a possible clash in one of the morphs input files.

A workaround seem to be to set the minimize tolerance parameter in freenrg.cfg to a much higher value than the default (1e-08). I have been playing with a value of 1.0 and was able to eliminate errors in the test case I am working on at the moment. Further testing is needed certainly.

And...be careful with the OpenMM minimizer as the output may in fact not be minimized after a few minutes of minimization (the energy may even have gone up !)

[ppxasjsm]

This sounds promising. I'll make sure that the tolerance has a reasonable default value! The tolerance is given in 1*kJ/mol. Maybe something like 100 would be a reasonable value then?

[ppxasjsm]

Done