Hello,
It is my intention to extend the Amber parameter file format to support
arbitrary Lennard-Jones sigma and epsilon pairs, and to do this by
augmenting the parm*.dat reading and prmtop writing capabilities of tleap.
I am making good progress understanding the tleap code and implementing
my solution using the data structures that Christian Schafmeister and
David Rivkin did in the early 1990s, and crafting the extended format in
such a way as will be backwards-compatible. However, I will need the help
of other Amber Devs to point out other instances in which the new
information may be relevant, or other programs which may need to learn the
extended format.
In developing a complete force field built around the new charging
protocol that I have developed, I have realized that it is in fact quite
hard to change the Lennard-Jones parameters in the existing ff99 / ff03 /
ff12 force fields without compromising the internal energy landscapes of
protein residues. The larger Lennard-Jones parameters I derived to obtain
the correct hydration free energies of side chain analogs make it
considerably harder to fit torsion parameters that make up the energy
differences between MP2 quantum data and the moleuclar mechanics energies,
probably because of 1:4 clashes.
The solution I have settled on is to keep the Lennard-Jones pair combining
rule and the original parameters for all protein:protein interactions, but
to change the protein:water pair interactions. The parm*.dat files will
have a new, optional section of the format
LJEDIT
<Type 1> <Type 2> <R* pair> <Eps pair>
...
END
This will look very much like the "MOD4 RE..." nonbonded terms section,
but with two type specified. The reader will check that both types exist
in the PARMSET as it compiles a list of these edits, and when it comes
time to write a prmtop with Lennard-Jones ACOEF and BCOEF terms it will
reference this list and include the adjustments. Are there any other
instances in which the output of tleap would need to know these terms? I
don't think that library files would need to know, as they are all written
with the assumption that there is a single pair combining rule and
atom-type specific sigma and epsilon parameters that form the matrix of
interactions. In my scheme, a force field could reference the existing
library files, and through the parm*.dat file implement force-field
specific modifications for pair potentials.
One might ask why put it in parm*.dat rather than a frcmod file, but I can
certainly check for the extension in frcmods as well. In making a new
force field I like to have everything in a single file--frcmods are for
anyone who wants to make edits to the original work.
There have been other thrusts in this direction before, particularly with
protien:water hydrogen interactions and talk of arbitrary sigma/epsilon
pair terms implemented through parmEd. The reason I am choosing to do
this without parmEd is that I want the Amber user base to experience no
difference in implementing ff13 (my new FF) as opposed to ff99. To do
otherwise would risk "silent errors" wherein the prmtop is created with
the wrong parameters. These things can happen already if someone wants to
change the water model and forgets to include an extra line in the input
file, and I worry that it would be much worse if someone has to take the
created prmtop and then run it through another program. parmEd is great
for experimenting, but I want ff13 to be a drop-in replacement for
existing force fields, from the PDB download to the trjaectory analysis.
Dave
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Jan 21 2013 - 11:00:03 PST
