<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Hi,<br><br>I coded this and I looked at the code again.<br>pbcatom is always the global, system wide atom number.<br>But it seems that mdrun forgets to add one to the atom number<br>or maybe this is part of the mdrun output scheme of starting numbering at 0.<br>We would have to check this.<br><br>As far as I can see that is consistent with your results, right?<br><br>Berk<br><br>> Date: Sun, 20 Jun 2010 18:54:13 -0400<br>> From: chris.neale@utoronto.ca<br>> To: gmx-users@gromacs.org<br>> Subject: [gmx-users] pull_pbcatom reporting strangely when set to 0<br>> <br>> Dear gromacs users:<br>> <br>> I am confused (again) about pull_pbcatom0. From this analysis, I am <br>> questioning if the pbcatom reported from grompp and in the top of the <br>> .log file is numerically defined *within* a group or in the context of <br>> the entire .gro file.<br>> <br>> Either way, I think that I have conclusively shown below that setting <br>> pull_pbcatomN to 0 is not reported properly. My hunch is that it is <br>> just a reporting problem and is working alright. For the reporting by <br>> grompp and at the beginning of mdrun, I think that the pbcatom is <br>> defined *within* a group, but that the selection of the pbcatom when <br>> setting pbcatom=0 is incorrect (sometimes drastically).<br>> <br>> I'm posting to the mailing list in the hopes that somebody can simply <br>> take a look at the relevant code and see where the problem is.<br>> <br>> Here, I have a .gro file that has protein, then lipid, then water. I <br>> have the lipid as pull group 0 and the protein as pull group 1.<br>> The protein has 14 atoms and the lipid group has 3456 atoms.<br>> <br>> These tests have all been run with 4.0.7 (and also 4.0.5 gives <br>> identical results).<br>> <br>> If I specify pull_pbcatom0=10 in my .mdp, then:<br>> <br>> grompp says:<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 10<br>> 1 14 7 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {14,...,3469}<br>> weight: not available<br>> pbcatom = 9<br>> <br>> This makes me think that at this stage the pull_pbcatom0 is defined <br>> within the group such that the accessible numebrs are [0,...,3455] -- <br>> If this was not the case, then pbcatom0 should be reported as 9+14 <br>> protein atoms = 25.<br>> <br>> ####################################################################################<br>> Ok, so now I define pull_pbcatom0=0 in my .mdp, then:<br>> <br>> grompp says:<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 1742<br>> 1 14 7 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {14,...,3469}<br>> weight: not available<br>> pbcatom = 1741<br>> <br>> Which surprised me because 3456/2=1728 and 1728 -1 (use zero as first <br>> #) +14 (protein atoms) = 1741<br>> <br>> However, this suggests that at this stage the pull_pbcatom0 is defined <br>> in the context of the entire .gro file, not only within the group. <br>> This contradicts what I saw above.<br>> <br>> ####################################################################################<br>> Next, I added a second protein (there are now 28 atoms of protein <br>> before the lipid coordinates start) and left pull_pbcatom0=0, now:<br>> <br>> grompp says:<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 1756<br>> 1 28 14 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {28,...,3483}<br>> weight: not available<br>> pbcatom = 1755<br>> <br>> Where 1755 = 1741+14 so again it looks as if the pull_pbcatom0 is <br>> defined (or at least decided) in the context of the entire .gro file.<br>> <br>> ####################################################################################<br>> ####################################################################################<br>> ####################################################################################<br>> Now I reverse the order of the protein and the lipid, with only one <br>> copy of the protein again.<br>> Here, I specify pull_pbcatom0=10 (pull group 0 remains the lipid):<br>> <br>> grompp says:<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 10<br>> 1 14 3463 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {0,...,3455}<br>> weight: not available<br>> pbcatom = 9<br>> <br>> ####################################################################################<br>> Now I specify pull_pbcatom0=0<br>> <br>> grompp says:<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 1728<br>> 1 14 3463 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {0,...,3455}<br>> weight: not available<br>> pbcatom = 1727<br>> ...<br>> pull_group 1:<br>> atom (14):<br>> atom[0,...,13] = {3456,...,3469}<br>> weight: not available<br>> pbcatom = 3462<br>> <br>> And from these last 2 I conclude that pull_pbcatom0 had better be <br>> defined in the context of the entire file, or else the 14 atom peptide <br>> having a pull_pbcatom of 3463 is going to be a real problem.<br>> <br>> #####################################################################################<br>> <br>> To test that, I removed all of the water so that the protein pbcatom <br>> would go out of bounds if it was really #3462 as defined within the <br>> group:<br>> <br>> gromp says (the exact same as before):<br>> Pull group natoms pbc atom distance at start reference at t=0<br>> 0 3456 1728<br>> 1 14 3463 -0.000 0.000 -0.001 0.000 0.000 0.000<br>> <br>> and the .log file says:<br>> pull_group 0:<br>> atom (3456):<br>> atom[0,...,3455] = {0,...,3455}<br>> weight: not available<br>> pbcatom = 1727<br>> pull_group 1:<br>> atom (14):<br>> atom[0,...,13] = {3456,...,3469}<br>> weight: not available<br>> pbcatom = 3462<br>> <br>> And it appears to be stable over 1000 steps of MD, so perhaps it's not <br>> going out of bounds.<br>> <br>> Thank you very much,<br>> Chris.<br>> <br>> <br>> <br>> -- <br>> gmx-users mailing list gmx-users@gromacs.org<br>> http://lists.gromacs.org/mailman/listinfo/gmx-users<br>> Please search the archive at http://www.gromacs.org/search before posting!<br>> Please don't post (un)subscribe requests to the list. Use the <br>> www interface or send it to gmx-users-request@gromacs.org.<br>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php<br> <br /><hr />Express yourself instantly with MSN Messenger! <a href='http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/' target='_new'>MSN Messenger</a></body>
</html>