[gmx-developers] Re: nstenergy and nstcalcenergy?

[hess at sbc.su.se]

A small clarification:
nstcalcenergy controls how often energies (and pressures) are calculated,
nstenergy controls how often the energies and their averages and
fluctuations are written. So setting nstcalcenergy to 10 will give
fully acccurate averages in the energy file (independently of nstenergy),
since energies are very correlated at intervals smaller than 10 steps.

Berk

> Hi all,
>
> I want to ask your opinion on the setup of mdp energy and coupling
> frequencies.
>
> In 4.0 and before energies were calculated at every step and T and P
> coupling were
> also done every step (except with mdrun -nosum).
>
> In 4.5 we try to do global summation less often (meaning calculating
> energies and
> T/P coupling) and PME solving is already cheaper without E and P.
> In future versions the innerloops will also be cheaper.
> So therefore I introduced nstcalcenergy which determines the frequency
> of energy
> calculation, T and P coupling.
>
> Michael Shirts suggested to have a separate nstcouple. But it currently
> never makes sense
> to have that set different from nstcalcenergy except for twin-range
> interactions, where the energy
> and pressure can only be calculated every nstlist steps and you might
> want to do T coupling
> every step (but doing that every nstlist is not a major issue).
> So I could add nsttcouple. nstpcouple does not make sense, because the
> only reasonable
> setting would be equal to nstcalcenergy.
>
> So my question is:
> Do we want only nstcalcenergy or nstcalcenergy and nsttcouple (or even a
> useless nstpcouple)?
>
> Berk
>
>
> Berk Hess wrote:
>> Not exactly.
>>
>> nstcalcenergy controls the calculation frequency of energies, which also
>> affects the statistics in the "exact" averages and fluctuations in the
>> energy files.
>> If this would not be the case we would not need a parameter at all and
>> we would
>> just need a conditional with many components in the md loop.
>>
>> I had thought of adding nstcouple, but that is yet another parameter
>> which the user
>> can set and also has to be checked against several other nst...
>> parameters for reasonable
>> performance. Currently there would not be an advantage to having the
>> freedom to
>> set nstcouple different from nstenergy, except for the NVT ensemble
>> where you only
>> need to determine ekin and no other energies or pressures.
>>
>> On the other hand, having an nstcouple might be easier to understand for
>> the user,
>> since then is it much clearer what the function of nstcouple and
>> nstcalcenergy is.
>>
>> Berk
>>
>> Shirts, Michael (mrs5pt) wrote:
>>
>>> Following up on the last one, currently nstcalcenergy controls the
>>> frequency
>>> at which coupling occurs. Perhaps there should be a nstcoupling, and
>>> then
>>> nstcalcenergy is determined as a function of nstcoupling, nstenergy,
>>> nstlist
>>> and any other variables that are affected, instead of controlling it
>>> directly?
>>>
>>> Best,
>>> ~~~~~~~~~~~~
>>> Michael Shirts
>>> Assistant Professor
>>> Department of Chemical Engineering
>>> University of Virginia
>>> michael.shirts at virginia.edu
>>> (434)-243-1821
>>>
>>>
>>>
>>>
>>>> From: "Shirts, Michael (mrs5pt)" <mrs5pt at eservices.virginia.edu>
>>>> Reply-To: "michael.shirts at virginia.edu" <michael.shirts at virginia.edu>
>>>> Date: Thu, 10 Jun 2010 17:41:06 -0400
>>>> To: "gmx-developers at gromacs.org" <gmx-developers at gromacs.org>
>>>> Subject: nstenergy and nstcalcenergy?
>>>>
>>>> I'm wondering about the relationship between nstenergy and
>>>> nstcalcenergy.
>>>> Is there a need for two variables?   This seems to lead to confusion.
>>>> For
>>>> example, one issue that's appearing is that when nstenergy = 1,
>>>> gromacs now
>>>> only computes the energy every nstcalcenergy steps.  It seems that
>>>> there
>>>> should be either one variable, or they should be synchronized in some
>>>> way.
>>>> Or perhaps change the variable names if they are actually controlling
>>>> something else.
>>>>
>>>> Best,
>>>> ~~~~~~~~~~~~
>>>> Michael Shirts
>>>> Assistant Professor
>>>> Department of Chemical Engineering
>>>> University of Virginia
>>>> michael.shirts at virginia.edu
>>>> (434)-243-1821
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> --
> 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.
>