[gmx-developers] MC integrator

[Berk Hess]

David Mobley wrote:
> There are some other times one might want MC even if MD is truly more
> efficient for most things we're interested in. THe examples that come
> to mind for me are particular kinds of moves for which MC might be
> dramatically more efficient, though these probably require extra work
> beyond "vanilla" MC:
> - Dihedral space moves of torsions -- for example to help sidechains
> with large barriers swap rotamers more quickly
> - GCMC for water insertion/deletion within specified regions (for
> example, water motions can be extremely slow in ligand binding sites;
> some recent work from the Roux lab used a GCMC approach in combination
> with normal MD to improve sampling of water).
>
> David
I agree (your second example is what I meant with different ensembles).

But for such specialistic cases, which can indeed provide an enormous
increase in simulation
efficiency, we do not so much need a MC integrator, but more an API that
can be called through scripts.
For your second example the TPI code provides the basic machinery for
efficient calculation.
For your first example some work would be require to only locally
reevaluate bonded and non-bonded
energies if you would want to do this often for many sidechains.

But I guess I might be better to focus our energy on setting up a proper
API.
Then users can write scripts to perform the MC parts of more complex
sampling schemes.

That is not to say that we not write an MC integrator.
Although I think most efficient type of MC moves will depend a lot on
the type of system.

Berk

>
>
> On Aug 6, 2009, at 3:12 AM, Berk Hess wrote:
>
>> Mark Abraham wrote:
>>> David van der Spoel wrote:
>>>> Mark Abraham wrote:
>>>>> David van der Spoel wrote:
>>>>>> Erik Marklund wrote:
>>>>>>> Swell! It's been missing from gromacs for a long time in my
>>>>>>> oppinion.
>>>>>>>
>>>>>>> Regarding parallelism, MC is highly parallelizable in
>>>>>>> "step-space", and computing different MC steps on different
>>>>>>> processors will most likely be faster than distributing particles
>>>>>>> or domains, since virtually nothing needs to be communicated.
>>>>>>> Therefore, a step-decomposition option is a good idea. Plus, it
>>>>>>> would be very easy to implement.
>>>>>>
>>>>>> This is not necessarily true if we move to many (tens of thousands
>>>>>> of processors) which soon will be feasible with gmx 4.1 once it is
>>>>>> finished. Hence I would prefer if the code did not "interfere" with
>>>>>> the parallellisation, but rather just uses the existing logic.
>>>>>> Maybe I misunderstand it, but you do a trial move and then
>>>>>> recompute the energy, right?
>>>>>
>>>>> Reworking the multi-simulation feature that already exists would be
>>>>> the best of all worlds. In REMD you have a bunch of the same system
>>>>> in different states, which sometimes move, but in straight MC you
>>>>> can have many copies of the same system computing different trial
>>>>> moves. The catch is that when you accept a move, you probably have
>>>>> to throw away any work on the old state and communicate the
>>>>> successful move to all systems. Does that suggest constructing
>>>>> low-probability moves to minimise wastage? Dunno.
>>>>
>>>> Multisim sits on top of the normal parallellisation, so you still
>>>> need to adapt to DD. But what could be simpler than handling the
>>>> trial moves sequentially? Nevertheless, once a DD implementation
>>>> works that does the trial moves sequentially, the Multisim solution
>>>> that you are suggesting would be simple to implement, and it would
>>>> lead to slightly higher efficiency probably.
>>>
>>> :-) By the same token, what could be simpler than *lots* of
>>> single-processor simulations that don't need any decomposition? For a
>>> number of processors sufficiently high with respect to the scaling
>>> limits of the domain decomposition, the computation lost when an
>>> accepted move means existing computation is worthless might be lower
>>> than the loss incurred by the decomposition communication.
>>>
>>> Or, if you don't need detailed balance, whenever a processor tries a
>>> move, it tells all other processors that they can't try any move that
>>> might clash. Then when one accepts a move, it communicates that to all
>>> the other processors who apply it when next convenient. Sampling comes
>>> from all replicas.
>>>
>>> Meh, time to quit with the random ideas, already :-)
>>>
>>> Mark
>> I think there is a much more serious issue with MC performance in
>> Gromacs.
>> Currently Gromacs is optimized to very efficiently determine the energy
>> of the whole system
>> with moves slowly with time.
>> For MC you want to be able to quickly evaluate changes in the energy due
>> to local moves.
>> In most cases this would mean that you would only want to go through the
>> neighborlist
>> of the atoms that move and compute the energy before and after the move.
>> You would never need the energy of the whole system.
>> How the efficiency turns out depends very much on the system size.
>> But MC might anyhow be inefficient for large systems.
>> Currently there is code for doing something similar, in the TPI
>> "integrator".
>> This only determines local energies, parallelism is handled through
>> giving
>> different "steps" to different processors, which in this case completely
>> decouple.
>> But performance wise TPI is much nicer than general MC, since can
>> perform
>> many insertions with a minor translation or rotation at the same
>> location
>> with the same local neighborlist.
>>
>> I think the solution depends a lot on what you would want to use MC for.
>> In most cases MD will be far more efficient than MC.
>> The only case I can think of where MC would do better is potential with
>> hard walls, in which case you can not use MD, but  in this case Gromacs
>> would not be suited anyhow.
>> Or maybe there are some special ensembles for which MD is inconvenient?
>>
>> Berk
>>
>> _______________________________________________
>> 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 thewww
> interface or send it to gmx-developers-request at gromacs.org.