[gmx-developers] Bond-angle coupling

[MURAT OZTURK]

Hello, thanks for both replies.

Properly generalized implementation seems well over my head, so I will
settle for a hacked-in solution for my particular case. My bonds will allow
re-binding, and I have a reasonable number of them, so I think I am safe in
this aspect. I will start working on this and very likely come back with
more questions.

But for now, I have one more question :

Let's say I have a tabulated bond between two particles. The table is as
long as the box size (let's say 10 nm) and it is a lj-cos potential so it
allows complete dissociation of these two particles. I get an error if
these particles get further than some threshold during simulation. I
believe that this threshold is due to domain decomposition. I want to have
tables as long as the box to allow complete dissociation. This way I will
not need any non-bonded interactions for my hydrogen bonds. Would it be
possible to ignore this threshold for my "hydrogen bonded" particles?

Particle decomposition comes to mind, but it says "only whole molecules can
be assigned to a processor" in the manual, which locks me into a single
processor as I have one enormous coarse grained molecule.

Cheers

Murat


On Thu, Oct 4, 2012 at 4:26 PM, Berk Hess <hess at kth.se> wrote:

> Hi,
>
> If you want to this completely generally, you would need 3-body non-bonded
> interactions. Gromacs is not well suited (yet) for this.
> If you have a limited number of hydrogen bonding partners,
> you can add a new (or modify) an "angle" potential function in bondfree.c,
> this is not to complicated. Then all HB pairs angles should be listed
> in your topology and all will be calculated (in parallel possibly not all).
>
> Cheers,
>
> Berk
>
>
> On 10/04/2012 02:56 PM, Bogdan Costescu wrote:
>
>> Hi!
>>
>> The functions for bonded interactions are all located in
>> src/gmxlib/bondfree.c. The functions are called on lists of atoms, one
>> list for one type of interaction potential. The caller already takes
>> care of splitting the lists between nodes, so you don't have to care
>> about this aspect. There is however another aspect that comes into
>> play: what happens after a bond becomes broken. The lists are "fixed",
>> as the topology is not supposed to change during the MD simulation, so
>> items from these lists will not magically appear or disappear. If the
>> bond potential is only based on distance and allows bond reforming,
>> there is no state to be kept and implementation is quite simple. If,
>> however, the bond has to remember the state (if it becomes broken it
>> has to remain broken), there are 2 ways:
>> - change the lists yourself - they have to be kept synchronized
>> between nodes, so it becomes a global operation which (if happens
>> often) will hurt scalability a lot
>> - keep the state of the bond and move it around with the atoms
>> whenever the atoms travel between domain decomposition cells
>> To make things more complex, if you want bonds to break and reform
>> with different partners, keeping the bond state doesn't help and
>> changing the lists is the only way.
>>
>> In terms of the actual potential, you might find some inspiration in
>> the cross_bond_bond() and cross_bond_angle() functions in the
>> bondfree.c file.
>>
>> Good luck!
>> Bogdan
>>
>> On Thu, Oct 4, 2012 at 2:28 PM, MURAT OZTURK <murozturk at ku.edu.tr> wrote:
>>
>>> Hello!
>>>
>>> I am thinking about hacking gromacs in the following way :
>>>
>>> I would like to have an angle potential that would turn on/off depending
>>> on
>>> the energy of a particular bond.
>>>
>>> For example, I will have a lennard-jones-cosine potential for a bonded
>>> interaction. This will continuously go to '0' at a threshold. Then I will
>>> have an angle potential between these two atoms (and a third one).
>>>
>>> For each calculation, I would like the angle potential to be multiplied
>>> by
>>> the instantaneous value of the bond potential, effectively turning it
>>> off if
>>> the bond is 'broken'.
>>>
>>> This is to represent a hydrogen bond in a coarse grained model.
>>>
>>> I have intermediate C/C++ skills (that I haven't used in a while), but I
>>> am
>>> intimidated by the parallel nature of the code and am not familiar with
>>> the
>>> internals of gmx. I am willing to work on this full time for a week or
>>> so.
>>>
>>> I would truly appreciate if someone could comment on the feasibility of
>>> this
>>> hack, and possibly show me where to begin.
>>>
>>> Thank you
>>>
>>> Murat
>>>
>>> --
>>> gmx-developers mailing list
>>> gmx-developers at gromacs.org
>>> http://lists.gromacs.org/**mailman/listinfo/gmx-**developers<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@**gromacs.org<gmx-developers-request at gromacs.org>
>>> .
>>>
>>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-**developers<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@**gromacs.org<gmx-developers-request at gromacs.org>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20121004/6821add6/attachment.html>