Re: [AMBER-Developers] constants and constants.f

From: Jason Swails <>
Date: Tue, 12 Oct 2010 11:20:55 -0400

OK, most likely my last post on this topic, as it's not an area I'm
particularly enjoying devoting time to. It seems that there is no *single*
value that I can choose for KB that will make all of the tests pass. I put
the value that I saw used in runmd.f in constants.f (and subsequently
replaced it in all other uses of boltzmann's constant in the src/sander
folder). It eliminated a large number of test failures. The only dhfr test
that does not pass fails with the following, sole diff:

possible FAILURE: check mdout.dhfr.dif
< NSTEP = 9 TIME(PS) = 510.059 TEMP(K) = 298.29 PRESS
= 0.
>  NSTEP =        9   TIME(PS) =     510.059  TEMP(K) =   298.28  PRESS
=     0.
All other dhfr tests passed, as did gb_rna tests.
However, RISM also uses the same constants module, but it actually makes use
of the constants (i.e. KB) inside, so changing KB to match (most of the)
sander test results of course causes small deviations in the RISM tests.
The options as I see them: stick with the *most* amber-consistent version of
the constants and clean up the tests that produce small failures (including
the RISM tests) OR I can discard everything I've done related to the
constants and stick with the status quo.  Thoughts are welcome.
On Mon, Oct 11, 2010 at 11:48 PM, Jason Swails <>wrote:
> On Mon, Oct 11, 2010 at 11:27 PM, case <> wrote:
>> On Mon, Oct 11, 2010, Thomas Cheatham III wrote:
>> >
>> > To date we have not held to a gold standard; in fact, the current lead
>> > (i.e. Pb) standard for a particular force field that we have applied
>> > to-date is code snapshot, run-time options, methods, and implementations
>> > used *at* the time the force field was developed.
>> I'll just note that the energies for the main DHFR test case (in
>> $AMBERHOME/test/dhfr/ have remained the same to all
>> printed
>> digits (about 9 significant figures) since Oct. 8, 2001.  That was when we
>> went from the "pure" leapfrog integrator to what is essentially velocity
>> verlet for estimating kinetic energies.
> These energies did indeed change very slightly (the last reported digit),
> though I certainly understand why it's desirable to keep identical results.
> However, I still don't think that KB should be separately defined every
> place it's needed.  Perhaps it's time to change the value of KB in the
> constants module to the one that's been used in runmd.f and the other files
> I used a replacement.  This seems to address all the issues.  I'll see if I
> can recover the *normal* results by plugging the *original* value for KB
> into the constants module.  This may not work if different functions use
> different values, in which case I think the tests should probably be
> changed.
>> The potential energies haven't changed since (at least) March 1999, which
>> is
>> as far back as the current git repo tracks things.  That was at Amber6,
>> when
>> (as I remember) we went to the current smooth PME implementation.  I'm
>> pretty
>> sure (tm) that Amber 5 had slightly different energies, traceable to a
>> slightly different PME implementation.
>> Since this is an NVE simulation, I don't think that changing pconv
>> should affect it, but I agree with Tom that one should be very careful
>> in changing constants by tiny amounts just for the sake of changing
>> constants.  The dhfr results, in particular, are de facto "correct",
>> having a
> I'm more advocating for changing in the interest of consistency and
> convenience of having only a single definition (and the safety that goes
> along with that) rather than just to make a change.
> I won't make any changes unless I can get all of these tests to pass with a
> single value defined in constants.f.
> Thanks!
> Jason
> decade or so of use both in our test suites and as the "jac" benchmark that
>> everyone now sees in NVIDIA clips.
>> [I know that a few hours ago I recommended updating the test cases, but
>> I've changed my mind, at least about some key NVE test cases; some of the
>> key GB tests like gb_rna should probably also remain unchanged.  Also, I'm
>> not counting formatting changes here, which *have* happened for dhfr.]
>> ....dac
>> _______________________________________________
>> AMBER-Developers mailing list
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
AMBER-Developers mailing list
Received on Tue Oct 12 2010 - 08:30:02 PDT
Custom Search