[gmx-users] Re: Re: Re: Re: Re: Re: umbrella potential
stefhoor at gmail.com
Tue Sep 22 15:25:23 CEST 2009
> 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
> 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
> > 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.
> > system returns to the initial dimer or tries to if the distance is too
> > 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
> > 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
> > same. I only change the "pull_rate" from 0.01 to 0 and "pull_geometry"
> > 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:
> > ------------------------------
> If the starting structures are not staying in the desired windows, it seems
> me that your force constant is not large enough to maintain these
> Try something larger, like 500 or 1000 like I suggested before and see if
> get a better result.
I will ty Justin's suggestion. I should have the answer by tomorrow.
As for Thomas' suggestion, well, my mdp file didn't even have the
"pull_start" flag. So I assume gromacs though I had set it to "no". But
anyway, I checked the force in each window as you mentioned andfound
something quite strange. The original pull_pf.xvg file, is an eve increasing
line starting at -43 kj/mol/nm. So when I check a specific time frame, the
pull force is, for example 93 kj/mol/nm at time frame 4000. But when I
checked the pull force on the pull_pf.xvg file at that specific window,
well, the pull force was something around -42 kj/mol/nm. Now I am really
confused. It seems I am doing something really wrong, but actually quite
simple to solve. I will try setting "pull_start = yes" and see what happens.
One other thing. I checked my pull_px.xvg file for the initial separation
trajectory. It looks like a a rollercoaster with a tendency to going down.
So the final value of distance PULL_COM is 1.5nm lower than the initial
value. The values on each of my windows are the same for the individual
values pf the separation trajectory from which they were taken. And again,
the values on the pull_px,xvg files all decrease.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-users