I should have waited for the QM/MM tests to finish. Those are all failing
(I did not change constants.f in src/sqm). I'm giving up and discarding the
changes.
On Tue, Oct 12, 2010 at 11:20 AM, Jason Swails <jason.swails.gmail.com>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.
>
> 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.
>
> Thanks!
> Jason
>
>
> On Mon, Oct 11, 2010 at 11:48 PM, Jason Swails <jason.swails.gmail.com>wrote:
>
>>
>>
>> On Mon, Oct 11, 2010 at 11:27 PM, case <case.biomaps.rutgers.edu> 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/mdout.dhfr.save) 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
>>> AMBER-Developers.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>
>>
>>
>>
>> --
>> 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
> 352-392-4032
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Oct 12 2010 - 09:30:03 PDT
