Maik,<br>
<br>
I agree with David on this one. It has been shown that using your
method can lead to pretty significant hysteresis, and it's difficult to
be sure whether you're going slow enough to equilibrate at any lambda
value. In addition, it's harder to parallelize (you are running one or
several long trajectories rather than a bunch of different
trajectories) and hard to extend (if you run at a bunch of different
lambda values, and you decide you need more sampling at one of them,
you can just extend that simulation; this way you have to start over
from scratch). Also, it's not clear, in my opinion, how to properly
estimate errors in this approach (I don't think there's a
straightforward way to compute the autocorrelation time, since the fact
that you are changing lambda as a function of time will affect apparent
correlations).<br>
<br>
With regards to using blocking to try and figure out the error from
your data, I don't know that this would work very well. Ideally, your
blocks should be of a length comparable to the autocorrelation time; if
you make them too short, you'll tend to underestimate the error, and if
you make them too long, you'll tend to overestimate it. But if you
can't figure out the autocorrelation time it's hard to know whether
blocking is working right, I think. <br>
<br>
To reiterate: My suggestion would be to avoid using slow growth. Run
simulations at fixed lambda values, which (a) works better, with no
hysteresis (and don't use the simulation at, say, lambda=0 as a
starting point for the simulation at lambda=0.1!), (b) is more
parallelizable, and (c) makes error analysis easier.<br>
<br>
David<br>
<br><br><div><span class="gmail_quote">On 1/17/06, <b class="gmail_sendername">Maik Goette</b> <<a href="mailto:mgoette@mpi-bpc.mpg.de">mgoette@mpi-bpc.mpg.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear all, dear David<br><br>Again a question concerning error estimation.<br>This time it's due to thermodynamic integration.<br>When I simulate my system, let's say 5 ns, from lambda 0 to 1, I get my<br>dG/dl values.<br>
At the moment, I am simulating both directions (0->1 & 1->0), integrate<br>over both, and the difference between my back and forth sims is the<br>error estimate.<br>But I think, one should use a method, similar to FEP, to "guess" the
<br>error from the dg/dl-data, maybe also with generating blocks with regard<br>to the autocorrelation.<br>But somehow, the delta lambda has to be included, not?<br><br>Regards<br><br>--<br>Maik Goette, Dipl. Biol.<br>Max Planck Institute for Biophysical Chemistry
<br>Theoretical & computational biophysics department<br>Am Fassberg 11<br>37077 Goettingen<br>Germany<br>Tel. : ++49 551 201 2310<br>Fax : ++49 551 201 2302<br>Email : mgoette[at]mpi-<a href="http://bpc.mpg.de">bpc.mpg.de
</a><br> mgoette2[at]gwdg.de<br>WWW : <a href="http://www.mpibpc.gwdg.de/groups/grubmueller/">http://www.mpibpc.gwdg.de/groups/grubmueller/</a><br>_______________________________________________<br>gmx-users mailing list
<br><a href="mailto:gmx-users@gromacs.org">gmx-users@gromacs.org</a><br><a href="http://www.gromacs.org/mailman/listinfo/gmx-users">http://www.gromacs.org/mailman/listinfo/gmx-users</a><br>Please don't post (un)subscribe requests to the list. Use the
<br>www interface or send it to <a href="mailto:gmx-users-request@gromacs.org">gmx-users-request@gromacs.org</a>.<br></blockquote></div><br>