[gmx-developers] milestoning

[Berk Hess]

Hi,

Actually the energy minimization already has a, very efficient, state 
resetting procedure.
It saves the state, or better: has two state structs and swaps pointers. 
The domain decomposition code already automatically handles "reloading" 
old states. As long as you directly call dd_partition_system right after 
resetting the state, I think this should also work for MD. Have a look 
at minimize.c for the simple procedure used there.

Cheers,

Berk

On 08/19/2013 03:38 PM, Mark Abraham wrote:
> On Mon, Aug 19, 2013 at 10:39 AM, Sergio Decherchi
> <Sergio.Decherchi at iit.it> wrote:
>> Dear M. Abraham,
>>
>> sorry to be so late. Thank you for your answers.
>> How many stateful variables are present in Gromacs?
> Depends what you're doing :-) ... but see below. Also, have a look at
> gmxcheck -cp yourfile.cpt - I think that will have a superset of what
> you'd need.
>
>> 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?
> The simplest thing for you to implement is writing checkpoint files to
> a memory-mapped file system every (integration? neighbour-search?)
> step and re-load only upon violation. This will still have horrible
> performance (e.g. there has to be global communication and in-memory
> construction of I/O buffers and copying of those buffers to "file,"
> but at least you won't hit actual disk), but may be good enough for
> you to prove the method is useful. A good implementation requires that
> the distributed forms of the data that go into the checkpoint file are
> copied locally in memory. This can be done, but one would want to be
> sure of using the implementation a lot to pay for the extra
> development time...
>
> Cheers,
>
> Mark
>
>> 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.
>> --
>> 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.