[gmx-developers] Shift for MARTINI force field?

XAvier Periole x.periole at rug.nl
Wed Oct 21 14:41:35 CEST 2009

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  
>>> Moritz
>>> et al. (linked by Michael) when using MARTINI with increasing time  
>>> step
>>> 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  
>>> energy.
>>> 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?
>> Cheers,
>> Luca
> 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?
> Micheal Shirts together with the group of Tuckerman has been looking
> into using
> the half step Ekin for coupling, but has not succeeded (yet).
> So we will have a more accurate Nose-Hoover/Parrinello-Rahman  
> integratore,
> but with less accurate temperatures.
> The nasty aspect of this Ekin inaccuracy is that different modes get
> affected differently,
> it is not a simply uniform scaling of the temperature.
> Berk
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.

More information about the gromacs.org_gmx-developers mailing list