Re: [AMBER-Developers] Amber atom type naming (and parms)

From: Thomas Cheatham III <>
Date: Thu, 15 Dec 2011 15:33:39 -0700 (Mountain Standard Time)

> There's also the issue of type HO which causes the catastrophic failure
> in those few circumstances where the right charged things all line up in
> just the right way. A tiny vdW term fixes it. Was mentioned last
> meeting.
> HO 0.2000 0.0300 M.B. Tessier 2011, use by permission only
> I think you were considering adopting it. Still?

These kind of silent changes are worrisome in that small changes can have
drastic effects. For example, the differences between true TIP3P water
and the TIP3SP model in CHARMM. Moreover, order dependence in force field
loading is going to bite people and be rather difficult to track down /

Although I agree as we move forward we should fix issues like phosphate
angles, etc. care is needed to understand the implications. For example,
does the HO vdw alter h-bonding strength or length? Does it alter
rotational barriers?

If ff99SB-GLYCAM06 modifies these, then the force field is not really
ff99SB + GLYCAM06 but GLYCAM06 + (silently) modified ff99SB.

This is why RCW is doing the lower-case upper-case combo for lipids; this
will not break any current force field, is logical, was not claimed as of
yet, and does not introduce order dependence in force field loading.
Similarly with GAFF all lower case. The fight now is on all caps names
and dealing with an increasingly large set of parameters needed for
proteins, nucleic acids and carbohydrates. I anticipate that with
pairwise additive nucleic acids we'll be moving to separate types for each
base furanose and potentially the backbone. We will run out of C? names.

Certainly food for thought the for the developers meeting. In an ideal
world we'd jump to 3-character (or more) atom types, however this would be
a challenging undertaking. Of course there are still lot's of other two
letter combinations....

In my opinion, as discussed on the list and at previous meetings by
others, we want the force fields to be orthogonal so that you can load
nucleic acid, protein, lipid, carbohydrate and drugs all-together without
worrying about silent force field modifications and/or order dependence.
Alternatively we could move to a model that does thing's sequentially,

load nucleic acid force field
load nucleic acid coords
load protein force field
load protein coords

However, then the prmtop would have to become more complicated to have
coordinate/atom name associated types so that a CA type could have
multiple meanings/values (i.e. we'd have to extend the prmtop and override
the current atom typing storage).


AMBER-Developers mailing list
Received on Thu Dec 15 2011 - 15:00:02 PST
Custom Search