Custom Search
--- > 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 _______________________________________________ AMBER-Developers mailing list AMBER-Developers.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber-developersReceived on Tue Oct 12 2010 - 08:30:02 PDT