[gmx-users] Re: Re: Re: Re: Re: Re: umbrella potential
gmx3 at hotmail.com
Tue Sep 22 11:59:35 CEST 2009
> Date: Tue, 22 Sep 2009 11:19:56 +0200
> From: schlesi at uni-mainz.de
> To: gmx-users at gromacs.org
> Subject: [gmx-users] Re: Re: Re: Re: Re: Re: umbrella potential
> Only an idea:
> If you start your pulling simulations (to get the windows) your spring
> start at some point (0.9nm?) and then moves along the pulling direction.
> If you now take a snapshot from the trajectory the spring is at 0.9+x nm
> . When you now change *only* the 'pull_rate' two things can happen:
> 1) 'pull_start=no' spring sits at the same point where it was at the
> beginning of the window-search simulation (-> force in the backward
> -> molecule moves back and spring helps it
> 2) 'pull_start=yes' spring sits exactly on top of the pull_group (and
> isn't elongated -> no force)
> -> molecule moves back till the force between the two molecules and the
> force between the spring and the pull-molecule are equal
> I think the best on can do is the following:
> Use 'pull_start=no'. Calculate the vector from group0 to group1 -> this
> is then the 'pull_init'. Then make the simulations from which you get
> your windows. Now take the time of each window and calculate with the
> pull_rate the distance which the spring moved. When you now simulate a
> window modify 'pull_init' with this distance -> Then the spring should
> be exactly at the same place, in which it was in your window-search
> But there is probably one problem: This could (with bad luck) only work
> for 'position' pulling, the other pull-protocols doesn't mention the
The description of pull_init makes clear (I hope) that pull_init works
for all protocols (except for constant force where the is not need for it).
> One think you can check is, if the force in the window-search simulation
> (time when you make the snapshot) and in the window simulation (first
> frames) should be the same (if one neglects fluctuations).
> Hope this helps or gives you an idea to solve the problem.
> > Ok, here is what I meant. I use each of the starting position extracted from
> > my original pulling trajectory (i mean the trajectory with "pull_rate =
> > 0.01") to simulate each window. Each of these windows still have the
> > umbrella force constant (pull_k1 = 35) but now have "pull_rate = 0". My
> > system, though, does not fluctuate about a mean position in each window. My
> > system returns to the initial dimer or tries to if the distance is too big
> > and the simulation time not long enough. So, whem I analyse the distance
> > between the two groups with g_dist in each of the sampling windows, I get a
> > series of decreasing values that will eventually return to the 0.9 nm.
> > For these simulations, I keep the same parameters as in the original pull
> > trajectory. The vectors are still the same, the force constant is still the
> > same. I only change the "pull_rate" from 0.01 to 0 and "pull_geometry" from
> > direction to distance (because g_wham asks tells me "pull_geometry =
> > direction" is not supported).
> > So maybe I am doing something wrong.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: http://lists.gromacs.org/pipermail/gmx-users/attachments/20090921/82a666ca/attachment-0001.html
> > ------------------------------
> gmx-users mailing list gmx-users at gromacs.org
> 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
What can you do with the new Windows Live? Find out
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-users