Thank you Berk,
I did not realize that one might want to use a pull_pbcatom that is
not part of the pull_group. In that case it makes sense that it should
remain a global atom index. My comment regarding being affected by
reordering the topology was indeed poorly constructed. What I meant was:
SOL 1000
Peptide 10
would require a different pull_pbcatom than
Peptide 10
SOL 1000
even if the pull_group was 'Peptide'.
Quoting your message:
"one can think of cases where an atom not part of the group is more central.
Code wise I don't see any reason why this should not work.
Are you sure that this does not work?"
Yes, it works fine, just not as I had expected. In my mistaken case, I
had placed pull_pbcatom0 as part of pull_group1 and ended up with a
pull_group0 that was often distributed to the corners of the box as
opposed to being in one central cluster.
Regarding the .ndx group, I agree that it is generally a waste of
time. It does, however, make it entirely clear that this is a global
atom selection. I am fine the way it is since I now understand it.
In case anyone is interested, I have placed a related item in the wiki
wishlist:
http://wiki.gromacs.org/index.php/Category:Development
Thank you again,
Chris.
--- original message ---
Hi,
pull_pbcatom is indeed a global atom index.
I will add this information to the mdp description.
I don't see how any atom number would not be affected by reordering
your topology,
except if you are thinking of group that consist of exactly one molecule.
But pull_pbcatom does not have to be part of the pull group.
Although in most cases user will choose it to be part of the group,
one can think of cases where an atom not part of the group is more central.
Code wise I don't see any reason why this should not work.
Are you sure that this does not work?
I don't see why you would want pull_pbcatom to take an index group.
Apart from the fact that this will complicate the option description
and processing,
you will have to make an index group with one atom index, which you would
otherwise fill in directly in pull_pbcatom.
Berk
Date: Mon, 23 Feb 2009 01:26:12 -0500
From: chris.neale at utoronto.ca
To: gmx-users at gromacs.org
Subject: [gmx-users] pull_pbcatom appears global and could benifit
from a sanity check during grompp
Hello,
I am using the pull code (umbrella, distance) to restrain molecule M
to a specified distance from group G in gromacs 4.0.4. I recently
found that I needed to specify pull_pbcatom(G) and restarted my
simulations using a rationally selected atom from that group.
However, the distance restraint appeared to stop working, even
though the forces output in the .pf.xvg file were large. I am by
now pretty sure that what pull_pbcatom requires is the global atom
number (ranging from 1 to N over the entire .gro file; sensitive to
topology reordering) and not the group-specific atom number
(ranging from 1 to G over the selected group; insensitive to
topology reordering). Actually, I had expected pull_pbcatom to
accept a .ndx file group, and when it didn't then I incorrectly
guessed the group-specific numbering as outlined above.
First, can anybody confirm this?
Second, my specified pull_pbcatom0 was not even part of pull_group0
if indeed the atom numbering is global. I think that there should
be a fatal error generated in this case.
Third, I suggest the following addition to the online .mdp option
text for the pull code pull_pbcatom:
Existing:
"The reference atom for the treatment of periodic boundary
conditions inside the group (this has no effect on the treatment of
the pbc between groups). This option is only important when the
diameter of the pull group is larger than half the shortest box
vector. For determining the COM, all atoms in the group are put at
their periodic image which is closest to pull_pbcatom1. A value of
0 means that the middle atom (number wise) is used."
To Add:
"When pull_pbcatom is greater than zero, the atom number is treated
globally and should therefore correspond to the atom number in the
.gro file as it would in an index file group. Hence, pull_pbcatom is
sensitive to a reordering of your topology"
Fourth, for the long term development I suggest that this should be
supplied as a .ndx file group.
Thanks,
Chris.
_______________________________________________
gmx-users mailing list gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
