continuations can report double the initial temperature
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 .
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.
#3 Updated by Berk Hess about 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 about 3 years ago
These same comments are also at https://redmine.gromacs.org/issues/2200 .
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: https://redmine.gromacs.org/issues/1376 . 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?