On Mon, Oct 11, 2010 at 3:09 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi All,
>
> If I might throw my 3 cents into the argument here. I believe what matters
> more is that the constants used are all internally consistent and not that
> they are technically perfectly correct. Remember the various force field
> parameters etc were all fitted and optimized using the constant values
> within the code as it stands now. If you changing these values then you
> should probably consider reparameterizing the force fields with the new
> constant values. If you don't then all you are really doing is making the
> error bars on the results slightly larger since the original error was
> folded into the fitting procedure empirically.
>
The only changes I've enacted on my local branch is to substitute KB from
constants.f in for 8.31blahblah, ZERO for 0.0d0/0.d0, ONE for 1.0d0, HALF,
etc., and of those the only truly significant one that's causing changes is
the changing of boltz2 to KB * HALF. In all of the tests that I've seen so
far, this has only affected the total kinetic energy (and therefore the
temperature), out to the last reported decimal place. Hardly grounds for
reparameterization, especially since it hasn't affected the potential energy
in the tests I've perused.
In general, I'd agree that fundamental changes to constants used throughout
the code would require a re-parameterization of force fields, but that's not
what I'm talking about here. My main push is for a centralized definition
of constants (like we have, but we don't always use) so that the same
constant has the same value everywhere in the code, and furthermore if we
ever want to change it and then systematically reparameterize, it's as
simple as changing a number in constants.f.
All the best,
Jason
> Now if the constants themselves are not self-consistent within the code
> then
> that is another matter entirely and this is what leads to inaccuracies in
> gradients etc.
>
> All the best
> Ross
>
> > -----Original Message-----
> > From: Jason Swails [mailto:jason.swails.gmail.com]
> > Sent: Monday, October 11, 2010 12:04 PM
> > To: AMBER Developers Mailing List
> > Subject: Re: [AMBER-Developers] constants and constants.f
> >
> > On Mon, Oct 11, 2010 at 2:41 PM, B. Lachele Foley <lfoley.uga.edu>
> wrote:
> >
> > > I'm not claiming to be elite, but I am a big fan of being exceedingly
> picky
> > > about these things. So, I vote to make them all the same and clean up
> the
> > > tests. In fact, go to NIST and make sure they are the official, most
> > > recent, umpteen-decimal versions. I also vote to make all the
> functions
> > use
> > > the same constants from one central
> >
> >
> > The problem with using everything from NIST is that, in many cases, we
> try
> > to be compatible with constants used in other packages (i.e. mopac,
> > gaussian, dynamo, etc.). IMO, every single package out there should have
> a
> > constants module that pulls from the most up-to-date, as-precise-as-
> > possible
> > values from NIST so using, for example, 0.529177249D0 (bohrs to angstroms
> > in
> > dynamo) vs. 0.52917706D0 (same in gaussian 98) doesn't actually cause any
> > differences.
> >
> > location unless there is some very good reason a certain function needs
> it
> > > to be different.
> > >
> >
> >
> >
> > >
> > > On that note, and showing my ignorance, is there a document somewhere
> > that
> > > lists all the units and values used in Amber, including, for example,
> the
> > > amusing choice of unit for charge? If not, that's my next manual
> > > suggestion.
> > >
> >
> > As an appendix? The constants.f file itself is fairly descriptive, and
> > provides sufficient documentation for the units. The Amber charge units
> I
> > believe are explicitly described somewhere, each charge having the
> > appropriate amount of the electrostatic constant such that the resulting
> > units are kcal/mol.
> >
> > I got distracted writing this email and Professor Case has responded a
> > couple times... I suppose I'll just send what I have :).
> >
> > (P.S., I'm not changing constants in sqm, just sander).
> >
> > Thanks!
> > Jason
> >
> >
> > > ________________________________________
> > > From: Jason Swails [jason.swails.gmail.com]
> > > Sent: Monday, October 11, 2010 2:09 PM
> > > To: AMBER Developers Mailing List
> > > Subject: [AMBER-Developers] constants and constants.f
> > >
> > > Hello,
> > >
> > > In the course of my work I've been rummaging through runmd.f, force.f,
> > and
> > > ew_force.f, and figured that while I was there I'd attempt some
> cleanups,
> > > like adding intent to variables and consolidating the use of constants.
> > > Particularly, Boltzmann's constant was defined separately in many
> different
> > > subroutines, so I changed it to KB from the constants module (as I
> think
> it
> > > should be). However, the values used in the various subroutines
> differed
> > > slightly from the value in constants.f, so now a very large number of
> tests
> > > are failing due to inconsistencies in the last reported decimal place
> for
> > > temperatures and kinetic energies in several places.
> > >
> > > My question is should I purge those changes or keep them and update the
> > > tests? Obviously, I'd have to pick through the tests and make sure
> that
> > > the
> > > changes are benign and caused by my changes to the value of boltz2, but
> I
> > > think it's worth consolidating the use of KB so the same value is used
> > > throughout the source code that originates from the same declaration.
> > > However, I thought I'd poll the Amber elite rather than run away with
> my
> > > ideas and assumptions.
> > >
> > > Thanks!
> > > Jason
> > >
> > > --
> > > 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
> > >
> > > _______________________________________________
> > > 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
>
>
> _______________________________________________
> 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 - 13:00:03 PDT
