Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type work around

From: Yong Duan <>
Date: Sun, 11 Dec 2011 08:50:52 -0800

Hi Lachele,

I thought CY is a rather ancient atom type and was in parm91.dat (and is
still there).

With several groups working on various flavors of force fields and the
need of ever increasing level of sophistication, some collisions of
atom-type definitions are almost inevitable. It's probably a sign of
convergence of ideas (or collisions of ideas, depending how you look at
it). It is great that this type of problems are known before we send it to
the users (or, was it the case??) and a work-around is available.

Testing by tleap/gleap/leap is one way to find things like this. But I
don't think it is realistic to have a bunch of tleap files that contain
all available information in parmxx.dat (and various versions). So,
something like what Scott's suggested will probably work better.

One potential solution is to use lower case as in GAFF which uses lower
case 2-letter strings for atom types. You may imagine mixed lower-upper
cases for GLYCAM. So, a CY, if there is a need to re-parameterize/rename
in GLYCAM, you'd call it Cy or cY.

Yong Duan, Ph.D, Professor
UC Davis Genome Center and
Department of Biomedical Engineering
University of California at Davis
Davis, CA 95616
On 12/10/11 10:26 AM, "B. Lachele Foley" <> wrote:
>We've been trying to figure out a way to bring this type naming thing up.
> We would like to implement some sort of new-type-generation procedure
>that will help keep force fields from introducing duplicate types.  This
>doesn't matter, of course, with two similar force fields, say for
>proteins.  But, for force fields that might get mixed, it totally
>matters.  When we chose CY, it almost certainly wasn't being used by
>anyone, and that's why we chose it.  But, there isn't a good way to
>declare that, so other folks don't know to avoid it.  We were planning to
>suggest a procedure rather than just complain, but... we are all so very
>We did check ours against the other force fields.  In fact, we have a
>program that will check for overlap between any two force fields, so we
>can do it automatically.  I don't recall the most recent results, but
>there were more of them.  I'll  check into how hard it will be to share
>the program.
>Yeah, will fix the repo.  Actually, we have a version h poised to pounce,
>too.  We still haven't made tleap tests, either.  Sigh.
>Oh.... last I recall... it works because... and I might have some of this
>backwards, but essentially:  Leap takes the first atom type assignment
>but the last force field parameter assignment.  So, we load leaprc for
>our stuff to set the atom types.   Duplicate types in 99SB get ignored,
>but the params from SB overwrite ours.  So, we reload our leaprc to set
>the params right, without affecting the types, which are all ignored.
>Got that info from observed behavior, not from inspecting code.
>:-) Lachele
>Dr. B. Lachele Foley
>Complex Carbohydrate Research Center
>The University of Georgia
>Athens, GA USA
>From: case []
>Sent: Saturday, December 10, 2011 9:24 AM
>Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type
>work    around
>On Sat, Dec 10, 2011, Jodi Ann Hadden wrote:
>> Currently there is an issue with the CY atom type which overlaps in
>> ff99SB and GLYCAM.
>Thanks for looking into this.  Note that ff10 and ff11r4 also have some
>new atom types for proteins.  Can you check for additional name overlaps.
>(You need to switch the "ff11" branch to get ff11 parameters.)
>> - Go to and download the most up-to-date version
>> of the parameters.
>It looks like Glycam_06g-1.dat is slightly different from the corresonding
>file (GLYCAM-06g.dat) in the git repo.  Can you bring the latter up to
>date, probably putting the full id in the header line, removing references
>to "Amber 8" etc.
>> - If you are building a system that contains a carbohydrate, load
>> GLYCAM, ff99SB, then GLYCAM again.
>> source leaprc.GLYCAM_06
>> source leaprc.ff99SB
>> source leaprc.GLYCAM_06
>Can you explain why this works?  Is there a fix going forward that
>the need for this workaround?
>AMBER-Developers mailing list
>AMBER-Developers mailing list
AMBER-Developers mailing list
Received on Sun Dec 11 2011 - 09:00:03 PST
Custom Search