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 > > ------------------------------ > _______________________________________________ gmx-users mailing list [email protected] http://lists.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 [email protected]. Can't post? Read http://www.gromacs.org/mailing_lists/users.php
