[gmx-developers] Shift for MARTINI force field?
hess at cbr.su.se
Wed Oct 21 14:48:46 CEST 2009
XAvier Periole wrote:
> On Oct 21, 2009, at 1:20 PM, Berk Hess wrote:
>> Luca Monticelli wrote:
>>> XAvier Periole wrote:
>>>> Also for your information. The derive of temperature reported by
>>>> et al. (linked by Michael) when using MARTINI with increasing time
>>>> is actually due to (the old story reported by van Gunsteren et al.)
>>>> the use
>>>> of the average of the half-time-step velocities to get the on-step
>>>> temperature instead of the average of the half-time-step kinetic
>>>> We have written a comment on that paper ... nothing wrong with
>>>> MARTINI. :))
>>> That is also my understanding, thanks Xavier for clarifying this.
>>> By the way, I think it would be useful if we were able to choose how
>>> to calculate the kinetic energy (either from average half-step
>>> velocities, as was done until v3.2.1, or from half-step kinetic
>>> energies, as done in v3.3 and newer). At the moment, one needs to use
>>> the (much slower) v3.2.1 to look at the effect of calculating the
>>> kinetic energy in 2 different ways. Would it be a lot of work to add
>>> an implementation of the "old way" in Gromacs 4? (and then allow the
>>> user to choose between the two)
>>> I did notice large differences (in the density of liquids, for
>>> example) between v3.2.1 and v3.3 with MARTINI (with atomistic
>>> simulations the differences are less important since the time step is
>>> much smaller); it's clear that this is related to the different way of
>>> calculating kinetic energy, but it's not entirely clear to me why the
>>> new method would be best. I suppose Berk has done some work on this,
>>> but I haven't seen any paper published - did I miss it?
>> The situation is clear:
>> the error in the full step kinetic energy is exactly 4 times as high at
>> the half step kinetic energy.
>> Therefore the half step kinetic energy is always better than the full
>> step one.
>> I don't see any reason for having the option to output the full step
>> kinetic energy,
>> except for exact comparison against more incorrect results.
> There is also the fact that there is a constant term that will
> alway differentiate the two temperatures (obtained from <v> or <K>).
> This comes due the quadratic effect in using differences between
> half time step velocities and Ek. One is the scare of the other.
> This term is function of the difference between consecutive half time
> step velocities which will increase with the time step. Note that the
> half time step velocities are themselves not affected by the time step
> only the difference between them!
> One other thing is that if you use the one-step velocity obtained from
> averaged velocities to couple our system and output it ... everything
> look fine but the half-time step temperature (from the half time step
> would be much lower, indicating that the system itself runs at a much
> conclucion: GROMACS does pretty good.
>> Also note that GROMOS had (and as far I as know still has) the issue of
>> inconsistent temperature
>> calculation. The half step temperature is used in the temperature
>> coupling, whereas the full step
>> one is reported in the output.
> This is correct. From my understanding in GROMOS a correction to the
> temperature given in the output has to be applied to obtain the actual
> temperature of the system. This difference is the one I mention above.
>> Unfortunately this half step/full step issue will soon be reintroduced
>> in Gromacs,
>> because the velocity verlet integrator uses full time step velocities
>> for coupling.
> This might not be a good idea! Can't you leave leap frog?
Velocity-verlet is an additional option, it will not replace leap-frog.
This issue by itself is enough for me to prefer leap-frog in nearly all
More information about the gromacs.org_gmx-developers