request for changes to repl_ex_nst to issue a warning, rather than a note
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.
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.
#2 Updated by Berk Hess over 3 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?
#5 Updated by Berk Hess over 3 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: