Feature #1494

request for changes to repl_ex_nst to issue a warning, rather than a note

Added by Chris Neale over 6 years ago. Updated over 6 years ago.

Target version:


Using gromacs 4.6.1, I set -replex 250 but got exchanges every 300 steps instead. I gather that this is because nstcalcenergy now defaults to 100 (see issue 695 for resetting of repl_ex_nst to be a multiple of nstcalcenergy).

In the log file, I have:
NOTE: nstcalcenergy changes repl_ex_nst to 300

However, I didn't notice this for quite some time. It's not a big problem, and I know that you try not to out-think the user, but the combination of the code resetting variables on the fly and developers making changes to defaults can lead to users not getting what they intend (and not knowing so).

For instance, in gromacs 4.5.5, nstcalcenergy defaulted to -1 (in src/kernel/readir.c):

  ITYPE ("nstcalcenergy",ir->nstcalcenergy,     -1);
Such that it was then reset to 10, which is what made be think that I could do exchanges every 250 steps.

However, in gromacs 4.6.1, nstcalcenergy now defaults to 100 (in src/kernel/readir.c):

    ITYPE ("nstcalcenergy", ir->nstcalcenergy, 100);

Leading to my confusion.

I think that a warning is better (causing the job to stop without -maxwarn being set sufficiently high), plus a detailed description of what is going on, so that the user at least knows what they are getting.

Thank you,

Associated revisions

Revision ec74f525 (diff)
Added by Berk Hess over 6 years ago

Decoupled repl_ex_nst from nstcalcenergy

The replica exchange frequency is automatically changed by mdrun
to a multiple of nstcalcenergy, which is annoying. It turns out that
it doesn't need to be a multiple, so this changing has been removed.
Fixes #1494

Change-Id: I00833f92fd468924f61879aff8b7c85fe79d3c2e


#1 Updated by Chris Neale over 6 years ago

strikeout text was not intentional in the above comment. Somewhat ironically, it was auto-formatted based on the negative sign ;)

#2 Updated by Berk Hess over 6 years ago

  • Category set to mdrun
  • Status changed from New to Feedback wanted
  • Assignee set to Berk Hess
  • Target version set to 5.0

But the replica exchange frequency is an option of mdrun, which doesn't have a terminate on warning option. The only option is to make it a fatal error. Would you prefer this?

#3 Updated by Chris Neale over 6 years ago

I would much prefer the fatal error to the unexpected (though documented in the log file) behaviour.

#4 Updated by Gerrit Code Review Bot over 6 years ago

Gerrit received a related patchset '1' for Issue #1494.
Uploader: Berk Hess ()
Change-Id: I00833f92fd468924f61879aff8b7c85fe79d3c2e
Gerrit URL:

#5 Updated by Berk Hess over 6 years ago

  • Status changed from Feedback wanted to Fix uploaded

Initially I thought that repl_ex_nst wouldn't need to be linked to nstcalcenergy, then I thought it should, because of global signalling. But the global signalling doesn't need to happen at repl_ex_nst steps, so it's fine anyhow. I pushed up a patch which completely removes the issue:

#6 Updated by Mark Abraham over 6 years ago

  • Description updated (diff)

Edited description. Berk's fix resolves the issue as far as I can see.

#7 Updated by Erik Lindahl over 6 years ago

  • Status changed from Fix uploaded to Resolved

#8 Updated by Berk Hess over 6 years ago

  • % Done changed from 0 to 100

#9 Updated by Erik Lindahl over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF