[gmx-developers] ensemble code and restraints

Berk Hess hessb at mpip-mainz.mpg.de
Wed Dec 10 18:00:17 CET 2008


Hi,

I implemented sub-ensemble averaging for distance restraints.
Currently the selection is not via an mdp or command line option,
but with the env.var.:
GMX_DISRE_ENSEMBLE_SIZE
Set this to the number of systems that you want to average over.

Berk

Robert Fenwick wrote:
> That is a great tip, thanks.
>
> 2008/12/9 Berk Hess <hessb at mpip-mainz.mpg.de>:
>   
>> 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.
>>>
>>>       
>> _______________________________________________
>> 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.
>   




More information about the gromacs.org_gmx-developers mailing list