Bug #2199

continuations can report double the initial temperature

Added by Mark Abraham over 3 years ago. Updated over 3 years ago.

Target version:
Affected version - extra info:
probably all of them for a long time
Affected version:


The 20ns log file shows temperature around 301K, the (group-scheme continuation) log files show about double that

20ns.log:Initial temperature: 301.894 K
20-40ns.part0002.log:Initial temperature: 598.241 K
40-60ns.part0003.log:Initial temperature: 601.259 K
60-80ns.part0004.log:Initial temperature: 599.191 K

Files from report by Elizabeth Ploetz on gmx-users .

nativeUBQ_6kbarLogFiles.tar.gz (6.02 MB) nativeUBQ_6kbarLogFiles.tar.gz Mark Abraham, 06/02/2017 02:51 AM

Related issues

Related to GROMACS - Bug #745: Double temperature written in log file when starting from checkpointClosed04/30/2011

Associated revisions

Revision 60b3dfd2 (diff)
Added by Berk Hess over 3 years ago

Fix initial temperature reporting

When continuing a simulation from a checkpoint, mdrun could report
double the intial temperature when nstcalcenergy=1 of nsttcoupl=1.
Note that this only affected reporting, the actual velocities were
Now the initial temperature is no longer reported for continuation
runs, since at continuation there is no "initial" temperature.

Fixes #2199.

Change-Id: Ib165620f0b6228e96b412ce7b8fdb681d7701b68


#1 Updated by Mark Abraham over 3 years ago

  • Related to Bug #745: Double temperature written in log file when starting from checkpoint added

#2 Updated by Gerrit Code Review Bot over 3 years ago

Gerrit received a related patchset '1' for Issue #2199.
Uploader: Berk Hess ()
Change-Id: gromacs~release-2016~Ib165620f0b6228e96b412ce7b8fdb681d7701b68
Gerrit URL:

#3 Updated by Berk Hess over 3 years ago

  • Category set to mdrun
  • Status changed from New to Fix uploaded
  • Assignee set to Berk Hess
  • Target version set to 2016.4

Only the reporting in incorrect by a factor of 2, the actual simulation is fully correct.
I uploaded a fix that removes the initial temperature printing at continuation.

PS Your simulation settings are strange. They are extremely inefficient with group scheme, nstlist=1 and nstcalcenergy=1. But there are not very accurate either, since you are using a list buffer of only 0.05 nm. Your simulations would go much faster and be more accurate when using the group scheme with default settings. Futhermore, I see Cmap energy entries, so I assume you are using the CHARMM force field. That should officially be used with force switching with LJ up to 1.2 nm.

#4 Updated by Elizabeth Ploetz over 3 years ago

These same comments are also at .

Hi Berk,

Thanks for your comments. I was trying to have accurate simulations, at the price of them being slow.
I switched most of my simulations to these strange settings (nstlist=nstcalcenergy=nsttcouple=nstpcouple=1) after this experience with polarizable simulations: . Do you think it is actually wrong or just slow? Why would it not be accurate if there is no list and everything is updated every step?

Where are you seeing a list buffer of 0.05nm?

Yes, this is the DE Shaw modified version of CHARMM22*. According to the reference
S. Piana, K. Lindorff-Larsen, D.E. Shaw
Atomic-level description of ubiquitin folding
Proc. Natl. Acad. Sci. U. S. A., 110 (15) (2013), pp. 5915–5920
(page 5916, left hand side),
"Nonbonded interactions were truncated to 10.5 Å, and the Gaussian Split Ewald (GSE) method was used to account for long-range electrostatic interactions (60)."
I was trying to implement the force field as the authors did. Do you think it is wrong?

#5 Updated by Berk Hess over 3 years ago

  • Status changed from Fix uploaded to Resolved

#6 Updated by Berk Hess over 3 years ago

#7 Updated by Mark Abraham over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF