<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/04/2012 04:00 PM, MURAT OZTURK
wrote:<br>
</div>
<blockquote
cite="mid:CAHz3uEV3-SCDVeqhhZLnV9jxc2Vg6V+g+g43h2XgecKoO+86Tg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Hello, thanks for both replies.
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>But for now, I have one more question : </div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
</blockquote>
I implemented the mdrun -noddcheck option is exactly for this
purpose.<br>
<br>
Cheers,<br>
<br>
Berk<br>
<blockquote
cite="mid:CAHz3uEV3-SCDVeqhhZLnV9jxc2Vg6V+g+g43h2XgecKoO+86Tg@mail.gmail.com"
type="cite">
<div>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. </div>
<div><br>
</div>
<div>Cheers</div>
<div><br>
</div>
<div>Murat<br>
<br>
</div>
<br>
<div class="gmail_quote">On Thu, Oct 4, 2012 at 4:26 PM, Berk Hess
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
If you want to this completely generally, you would need
3-body non-bonded<br>
interactions. Gromacs is not well suited (yet) for this.<br>
If you have a limited number of hydrogen bonding partners,<br>
you can add a new (or modify) an "angle" potential function in
bondfree.c,<br>
this is not to complicated. Then all HB pairs angles should be
listed<br>
in your topology and all will be calculated (in parallel
possibly not all).<br>
<br>
Cheers,<br>
<br>
Berk
<div>
<div><br>
<br>
On 10/04/2012 02:56 PM, Bogdan Costescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
The functions for bonded interactions are all located in<br>
src/gmxlib/bondfree.c. The functions are called on lists
of atoms, one<br>
list for one type of interaction potential. The caller
already takes<br>
care of splitting the lists between nodes, so you don't
have to care<br>
about this aspect. There is however another aspect that
comes into<br>
play: what happens after a bond becomes broken. The
lists are "fixed",<br>
as the topology is not supposed to change during the MD
simulation, so<br>
items from these lists will not magically appear or
disappear. If the<br>
bond potential is only based on distance and allows bond
reforming,<br>
there is no state to be kept and implementation is quite
simple. If,<br>
however, the bond has to remember the state (if it
becomes broken it<br>
has to remain broken), there are 2 ways:<br>
- change the lists yourself - they have to be kept
synchronized<br>
between nodes, so it becomes a global operation which
(if happens<br>
often) will hurt scalability a lot<br>
- keep the state of the bond and move it around with the
atoms<br>
whenever the atoms travel between domain decomposition
cells<br>
To make things more complex, if you want bonds to break
and reform<br>
with different partners, keeping the bond state doesn't
help and<br>
changing the lists is the only way.<br>
<br>
In terms of the actual potential, you might find some
inspiration in<br>
the cross_bond_bond() and cross_bond_angle() functions
in the<br>
bondfree.c file.<br>
<br>
Good luck!<br>
Bogdan<br>
<br>
On Thu, Oct 4, 2012 at 2:28 PM, MURAT OZTURK <<a
moz-do-not-send="true"
href="mailto:murozturk@ku.edu.tr" target="_blank">murozturk@ku.edu.tr</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<br>
I am thinking about hacking gromacs in the following
way :<br>
<br>
I would like to have an angle potential that would
turn on/off depending on<br>
the energy of a particular bond.<br>
<br>
For example, I will have a lennard-jones-cosine
potential for a bonded<br>
interaction. This will continuously go to '0' at a
threshold. Then I will<br>
have an angle potential between these two atoms (and a
third one).<br>
<br>
For each calculation, I would like the angle potential
to be multiplied by<br>
the instantaneous value of the bond potential,
effectively turning it off if<br>
the bond is 'broken'.<br>
<br>
This is to represent a hydrogen bond in a coarse
grained model.<br>
<br>
I have intermediate C/C++ skills (that I haven't used
in a while), but I am<br>
intimidated by the parallel nature of the code and am
not familiar with the<br>
internals of gmx. I am willing to work on this full
time for a week or so.<br>
<br>
I would truly appreciate if someone could comment on
the feasibility of this<br>
hack, and possibly show me where to begin.<br>
<br>
Thank you<br>
<br>
Murat<br>
<br>
--<br>
gmx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:gmx-developers@gromacs.org"
target="_blank">gmx-developers@gromacs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.gromacs.org/mailman/listinfo/gmx-developers"
target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list.
Use the<br>
www interface or send it to <a moz-do-not-send="true"
href="mailto:gmx-developers-request@gromacs.org"
target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote>
</blockquote>
<br>
-- <br>
gmx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.gromacs.org/mailman/listinfo/gmx-developers"
target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use
the www interface or send it to <a moz-do-not-send="true"
href="mailto:gmx-developers-request@gromacs.org"
target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>