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

[Berk Hess]

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 at 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-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php

_________________________________________________________________
See all the ways you can stay connected to friends and family
http://www.microsoft.com/windows/windowslive/default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20090224/0492ac8f/attachment.html>