[gmx-users] pull_pbcatom appears global and could benifit from a sanity check during grompp

[chris.neale at utoronto.ca]

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.