[gmx-developers] MC integrator

[Mark Abraham]

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