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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 11 2010 - 21:00:03 PDT
