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

[chris.neale at utoronto.ca]

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.