> Then, for each forcefield there should be exact specification of what is
needed in the
> prmtop for that forcefield, and what the data actually means (implying
how
it
> should be used).
Indeed, this is a problem which has caused confusion among users. The leap
scripts help a bit.
> BUT if you never do this and keep adding forcefields, you are going to
sink into a morass.
> This is less of an issue for me than it is for the amber group as a
whole,
> because I only intend to implement forcefields that are really
successful
> while in the sand(er)box. BUT what is a killler for me is if any
> fundamental objects in the current prmtop are changed or removed.
Here are the major changes in the ff that have taken place in the past 25
years since the inception of original AMBER.
1) united atom to all-atom (1986). No change is required in coding.
2) drop 10-12 terms (1994) and removal of lone-pairs. No change was
required
in coding.
3) addition of polarization and extra-points (2002). Need to change code.
All other changes have been updates (change of parameter values and number
of parameters) that did not alter the functional form of the potential
energy in any way and require no change in coding. Removal of 10-12 terms
actually simplify programs. Are you saying that we should keep 10-12
terms?
Calculations indicated that 10-12 terms were not needed in ff to represent
the energy functions. You are quite welcome to keep it in code, though.
So, the only concern we have now is the polarization. Are you saying that
we
should not support polarization (w/ or w/o extra-points)? I don't have a
crystal ball. Although, polarizable ff is not mature yet, it is going to
be
needed and become mature soon or later. As a package, we can either
support
it or become irrelevant soon or later.
Alternatively, did you really mean force field in the sense that I (and
perhaps a few others) thought what it meant? We refer the fundamental
parameter sets as the force field. For instance ff94 refers to the Cornell
charge and torsion set. Did you mean the "prmtop" file instead? Just in
case
...
Yong
Received on Wed Apr 05 2006 - 23:49:49 PDT
