[gmx-developers] ensemble code and restraints

[Berk Hess]

Hi,

It is slightly similar to that.
But if you want to set up a general scheme for doing this,
I think you would not only want to have pairs, but any number.
This is not hard to do with MPI.
The only thing you need is MPI_Comm_split, where you give
as an argument the same colour to each system that you want
to have in the same ensemble. Then you can simply replace
gmx_sum_sim in disre.c with a summation over the new communicator.

Berk

Robert Fenwick wrote:
> Hey Mark thanks for that, it does seem that this is a similar case.
>
> Bryn
>
> 2008/12/9 Mark Abraham <Mark.Abraham at anu.edu.au>:
>   
>> Robert Fenwick wrote:
>>     
>>> Hi Berk,
>>>
>>> It has been shown a few times now that averaging over a single
>>> structure is not sensible as it is possible to get strained
>>> structures, the other alternative is to do as you suggest to average
>>> over the whole ensemble. This also creates problems and if you average
>>> over three or more structures then it is possible that one completely
>>> unfolds while the others compensate. The same work has shown that if
>>> you average over pairs of structures you get around this problem. In
>>> theory I can do all of this in CHARMM. What I would like to know is
>>> how to implement a similar scheme in GROMACS, so that others can use
>>> it. I am currently lost in the source code and was looking for some
>>> pointers as to how I could get started.
>>>       
>> There are some implementation similarities between what you propose and
>> REMD. (I think) that at each(?) MD step you will need to swap certain atomic
>> positions between pairs of simulations so that each simulation master
>> process can then apply the pair-averaged restraint force without further
>> inter-simulation communication. In REMD, at every so many MD steps, you swap
>> the potential energy of certain pairs of simulations, and then maybe the
>> whole simulation state. You can get a fair idea of how you should approach
>> this project by understanding the REMD algorithm.
>>
>> Probably your most efficient implementation is to use some nonblocking MPI
>> sends and receives for the relevant subset of positions before you start
>> doing the normal nonbonded kernel loops, so that the communication completes
>> by the time you're done with the kernels and are ready to add in the
>> restraint forces. I've no idea how well that approach suits modifying the
>> existing implementation of intra-simulation restraints.
>>
>> Mark
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://www.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://www.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.
>