[gmx-developers] ensemble code and restraints
robert.fenwick at irbbarcelona.org
Tue Dec 9 12:32:40 CET 2008
That is a great tip, thanks.
2008/12/9 Berk Hess <hessb at mpip-mainz.mpg.de>:
> 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.
> Robert Fenwick wrote:
>> Hey Mark thanks for that, it does seem that this is a similar case.
>> 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
>>> 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
>>> 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
>>> this project by understanding the REMD algorithm.
>>> Probably your most efficient implementation is to use some nonblocking
>>> sends and receives for the relevant subset of positions before you start
>>> doing the normal nonbonded kernel loops, so that the communication
>>> 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.
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> Please don't post (un)subscribe requests to the list. Use the www
>>> or send it to gmx-developers-request at gromacs.org.
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> 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
> 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