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

From: case <>
Date: Tue, 12 Oct 2010 15:19:10 -0400

On Tue, Oct 12, 2010, Jason Swails wrote:

> 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
> /Users/swails/newamber/current/amber/test/dhfr
> 125c125
> < NSTEP = 9 TIME(PS) = 510.059 TEMP(K) = 298.29 PRESS
> = 0.
> ---
> > NSTEP = 9 TIME(PS) = 510.059 TEMP(K) = 298.28 PRESS
> = 0.

I could live with this change.

> 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.

I think this sort of thing needs to be attacked at (say) a developers'
meeting, where everyone can check the changes and discuss the consequences in
person, and real fist-fights can be used to sort out differences of opinion.
If just one person breaks a bunch of tests, everyone points the finger at that
person and stops believing the in the tests. So keep your notes handy, but
let's revisit this later.


AMBER-Developers mailing list
Received on Tue Oct 12 2010 - 12:30:03 PDT
Custom Search