[gmx-developers] milestoning

[Anton Feenstra]

Dear Sergio,

You may also want to have a look at grompy
(https://github.com/GromPy/GromPy). This is a python wrapper around the
gromacs 4.0.7 library, using direct C-library calls. This way, the whole 
state can be kept in-memory, but the generic gromacs routines for 
initializing and running simulations can be used. This would be 
equivalent to running grompp & mdrun from a shell-script, but without 
the huge overhead of repeatedly re-starting these programs from the shell.

One current application that we used this for is sampling the 
grand-canonical ensemble using a hybrid MC scheme. The overhead was 
reduced from 90% (shell script) to 6% (grompy), yielding a 14-fold speedup.
It seems to me that our GromPy implementation may also provide a 
solution for your Markovian Milestoning scheme.

The application is published here:
http://onlinelibrary.wiley.com/doi/10.1002/jcc.22947/abstract

Groetjes,

Anton Feenstra.

On 19/08/13 10:39, Sergio Decherchi wrote:
>
> Dear M. Abraham,
>
> sorry to be so late. Thank you for your answers.
> How many stateful variables are present in Gromacs?
>
> Anyway, to circumvent the problem of manually resetting all variables I could do the same
> operations done upon Gromacs restart.
> If I am able to restore the state of Gromacs as that from a restart file then everything should work
> because it is exactly as resetting the velocities at the beginning of a run.
> I only have to know the procedure which Gromacs uses to restart from a set of positions and velocities
> such that I can replicate that behaviour.
>
> In the end I need to do an in-memory restart. If I do it in that way all problems will disappear because in this
> way the reset is not distinguishable from a usual, from file, restart.
>
> If I want to set the state of Gromacs as that from a restart how can I do that?
>
> Thanks,
> Sergio Decherchi
> ________________________________________
> Da: gmx-developers-bounces at gromacs.org [gmx-developers-bounces at gromacs.org] per conto di Mark Abraham [mark.j.abraham at gmail.com]
> Inviato: venerdì 2 agosto 2013 16.40
> A: Discussion list for GROMACS development
> Oggetto: Re: [gmx-developers] milestoning
>
> On Wed, Jul 31, 2013 at 7:16 PM, Sergio Decherchi
> <Sergio.Decherchi at iit.it> wrote:
>>
>> Dear Gromacs Developers,
>> I would like to allow Gromacs to do Markovian Milestoning because it seems a
>> very
>> effective algorithm for the estimation of both free energy and kinetics. To
>> achieve
>> this goal I have to confine the simulation inside a Voronoi cell.
>> To do this confinment, in litterature it is suggested (see Venturoli and
>> Vanden Eijden "Markovian Milestoning") that one can, upon Voronoi cell
>> violation, invert velocities and reset the position to the previous
>> integration step such that the system can remain inside the Voronoi cell.
>>
>> I decided to interface to Gromacs via plumed2 such that collective variables
>> can be
>> used to compute the metric that rules the Voronoi cell.
>>
>> Following plumed2 philosophy I got velocities just before the do_force call
>> in md.c.
>> Assuming a velocity verlet integrator which are the velocities that I get in
>> this point of the code?
>> I mean, which time step?
>
> With VV, the positions and velocities are in sync at all times, by
> construction. Except during the update stage, of course, but obviously
> that is not happening right before do_force().
>
>> Do you suggest a specific strategy to invert velocities and set the previous
>> positions?
>
> There's no elegant way to do that. GROMACS is currently designed
> around the MD assumption that the next configuration will always
> evolve from the former. One would have to checkpoint the entire state
> in memory to be able to "roll back" like you might do with MC.
>
>> Gromacs expects an atom in a domain decomposition cell; after the reset of
>> the position to the previous step, this cell may have changed thus leading
>> to an inconsitency. I got this kind of problems.
>>
>> How can I set the positions to the previous integration step and at the same
>> time assuring
>> that Gromacs is aware of this change of positions from the domain
>> decomposition stand point?
>
> I gather the "fix" doesn't need recalculating forces. The simplest
> seam to use would be right before the update of positions and
> velocities. Construct backups of x and v at that point, call the
> update routines, check for whatever violations might arise, and fix
> them (either by changing the result of the update or changing the
> velocities that go into the update and then calling the update again).
> AFAIK, DD does not balance load between neighbour-search steps, and
> since the above intercept of the update phase completes before that
> even starts.
>
>> This problem can be avoided by using particle decomposition, but it is
>> probably suboptimal.
>>
>> I have done many trials and I have other issues.
>> Often lincs algorithm fails; when I compute
>> the 'reflection' on the Voronoi facet I use subset of atoms because the
>> metric is defined in a
>> subset of atoms. To get the maximal stability should I change velocities and
>> reset positions
>> of the whole system? Still lincs should be enabled or disabled at all?
>
> Not sure if your problems are intrinsic to the method or your attempts
> to implement it. LINCS will be fine if you've fed something physically
> reasonable into the update stage, but if you're abusing a bond by
> moving its atoms in awkward directions, LINCS will need help (at
> least).
>
> Mark
>
>> Thanks,
>> Cheers,
>> Sergio Decherchi
>>
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>


-- 
Groetjes,

Anton
  _____________ _______________________________________________________
|             |                                                       |
|  _   _  ___,| K. Anton Feenstra                                     |
| / \ / \'| | | IBIVU/Bioinformatics - Vrije Universiteit Amsterdam   |
|(   |   )| | | De Boelelaan 1081 - 1081 HV Amsterdam - Netherlands   |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
|             | Feenstra at few.vu.nl - www.few.vu.nl/~feenstra/         |
|             | "You Dirty Switch, You're On Again" (The Breeders)    |
|_____________|_______________________________________________________|