Project

General

Profile

Bug #2718

Several issues with Velocity Verlet and nstcalcenergy>1

Added by Berk Hess 9 months ago. Updated 9 months ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
mdrun
Target version:
Affected version - extra info:
all versions with md-vv
Affected version:
Difficulty:
uncategorized
Close

Description

The md-vv integrator computes energies when step-1 is a multiple of nstcalcenergy. A comment in the code says that this is because the first part of the loop belongs to the previous step. But several other booleans, among which energy file writing, free-energy and expanded ensemble use step and not step-1 to decide at which step to do things. So it looks like energies written to file and used for free-energy and expanded ensemble are outdated by nstcalcenergy-1 steps or can be zero or partially filled (at least in case of expanded ensemble).

My suggestion is to force nstcalcenergy=1 with md-vv in mdrun.

Associated revisions

Revision ef48ba37 (diff)
Added by Berk Hess 9 months ago

Correct VV integrator nstcalcenergy use

With velocity Verlet integrators, mdrun would compute energies
which contribute to averages in the energy output and might be
used for expanded ensemble calculcations one step too late.

Fixes #2718
Refs #2714

Change-Id: I67e4d00f7151ec9eb5dab6ca4e87b81ca12236e2

Revision 626e3818 (diff)
Added by Berk Hess 9 months ago

Work around expanded ensemble issues

Two bugs could cause expanded ensemble sampling to use
outdated or zero energies. In these cases mdrun now modifies
nstcalcenergy to 1 to avoid these bugs.

Note: This change should not be merged upstream, since there
is a proper fix for release-2019.

Refs #2714
Refs #2718

Change-Id: I79be9c5da55eaebb857bac6a98e6671720532e0e

History

#1 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2718.
Uploader: Berk Hess ()
Change-Id: gromacs~release-2018~Ida389284dd4e392503a216a03482fd481278930e
Gerrit URL: https://gerrit.gromacs.org/8619

#2 Updated by Berk Hess 9 months ago

Note that the instantaneous energies are correct, but the averages in the energy file contain both nstcalcenergy steps offset by one and nstenergy steps.

I think the actual solution is replacing step-1 by step for bCalcEnergy.

#3 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2718.
Uploader: Berk Hess ()
Change-Id: gromacs~release-2018~Ifb6567636d6ffdbdad2d1eadade7c415ce4bd086
Gerrit URL: https://gerrit.gromacs.org/8620

#4 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2718.
Uploader: Berk Hess ()
Change-Id: gromacs~release-2019~I67e4d00f7151ec9eb5dab6ca4e87b81ca12236e2
Gerrit URL: https://gerrit.gromacs.org/8622

#5 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2718.
Uploader: Berk Hess ()
Change-Id: gromacs~release-2018~I79be9c5da55eaebb857bac6a98e6671720532e0e
Gerrit URL: https://gerrit.gromacs.org/8623

#6 Updated by Mark Abraham 9 months ago

@Pascal Are there ways to use the ensemble validation machinery on such cases?

#7 Updated by Pascal Merz 9 months ago

Mark Abraham wrote:

@Pascal Are there ways to use the ensemble validation machinery on such cases?

Depends what goes wrong exactly:

  • If the energies are only shifted by a certain amount of steps, ensemble validation will not catch it (since the values are not wrong, just at a different time).
  • If a single energy value is zero or off (e.g. because some energy contributions were zero at the first writeout step), it will likely not be caught (single outlier in statistic).
  • If the energies are systematically zero or off (e.g. because some or all energy contributions are always zero), it's likely to be caught. Important to keep in mind, however, that the only way we have to check distribution of potential energies via their relative distributions at different temperatures - we could certainly design a case in which we calculate wrong energies with correct temperature-dependency, which we wouldn't be able to catch.

#8 Updated by Berk Hess 9 months ago

  • Status changed from In Progress to Resolved

#9 Updated by Mark Abraham 9 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF