[gmx-users] Re: Re: Re: Re: Re: Re: umbrella potential

[Thomas Schlesier]

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
direction)
-> 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
simulation.
But there is probably one problem: This could (with bad luck) only work
for 'position' pulling, the other pull-protocols doesn't mention the
'pull_init'.

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.
Greetings
Thomas

> 
> 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
> 
> ------------------------------
>