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

From: B. Lachele Foley <lfoley.uga.edu>
Date: Sun, 11 Dec 2011 23:03:14 +0000

I would still argue for a list because it will help people who are trying to decide which force fields can be used together. Since the Leap's don't complain if something is multiply defined, it becomes easy for parameters to silently be mis-loaded. And, while you can say "the user needs to learn to go look in the files," it seems we could make that a little easier. For example, if one merely looks at the defs at the top of parm94.dat, you would think CY isn't being used. And, it isn't -- except for a van der Waals-type equivalence near the bottom.

Perhaps CY wasn't a great choice, but it seemed as if parm91 was merely claiming it for some future use (as carbon-13, apparently), and its use had been mostly dropped by 94. In 94, its remaining as a vdW equivalent was probably just an oversight. So, it wasn't being used anymore, as far as we knew.

What I'm saying is that if an atom type is used in something so old it's been hidden down in "oldff", should we still worry about reusing it? In 04, the CY type hadn't been written significantly into a "parm" force field in 13 years. Maybe we shouldn't ever reuse, but there are only so many 2-letter combinations.

We can't just load glycam as a frcmod afterwards. The trouble is that the definitions are too different. Our CY is sp3, and others are sp2. So, we have to load our atom types, then their atom types, then their parameters, then our parameters.

:-) Lachele

Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.ccrc.uga.edu

________________________________________
From: Yong Duan [duan.ucdavis.edu]
Sent: Sunday, December 11, 2011 5:33 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type work around

The only entry I can find in the library is in protein.amberua.lib,

"CY" 12.010000 0.120000 1.850000 6 2 ""

Which is just an atom type definition.

In prep, both glycam04.in and GLYCAM_06.prep use CY.

Other than these, I don't see anywhere else referring to CY (other than
parmxx.dat).

If glycam-related force field parameters can be loaded as frcmod after
parmxx.dat, this problem should go away for now. I'd need to check with
Junmei to make sure we can rename it and to find out what other files need
to be changed.

CY was there in parm91.dat. Though not used, redefining it was probably
not the wisest decision. It's a lot safer to add new type than redefine
one. For long term, we do need to get a atom name scheme to avoid things
like this. I doubt a list is very helpful (make that "highly doubt"). For
instance, in this case, it was ignored.

There was a time when FEP-type calculations were the bread-butter
calculations in Peter's group. Those calculations often require "novel"
atom types. I suspect some of the atom types were defined then to help the
FEP calculations.


--
Yong Duan, Ph.D, Professor
UC Davis Genome Center and
Department of Biomedical Engineering
University of California at Davis
Davis, CA 95616
530-754-7632
On 12/11/11 9:52 AM, "B. Lachele Foley" <lfoley.uga.edu> wrote:
>Parm91 had *something* assigned to almost every C[A-Z] plus some others.
>But, they weren't all used.  For example, there are no actual parameters
>assigned to CY.
>
>$ grep -w CY parm91.dat
>
>CY 13.02                ?
>C   CX  CY
>
>So, it was, from an outsider's point of view, rather gratuitously
>reserved.  It was also not used in parm94:
>
>$ grep -w CY parm94.dat
>
>C   C*  CA  CB  CC  CN  CM  CK  CQ  CW  CV  CR  CA  CX  CY  CD
>
>In both these cases, CY was just assigned as an equivalent to C for vdW
>info, which seems a pretty dangerous thing to do in general.  But, more
>importantly, CY wasn't *actually* being used.  So, it seemed a fair
>target.
>
>Glycam was first developed to work with Parm94.  Around that time, the
>type CG (also previously used) was reassigned to mean "glycan carbon".  I
>can't possibly comment on the relative timings, but at some point, both
>glycam and 99 started actually using CY.  I do not know if either
>announced to the other.  I'm pretty sure this all happened before I got
>here (and certainly before I knew enough to know what was happening).
>
>Making use of case-sensitivity is a reasonable way to go.  But, it would
>be nice not to have to worry about conflicting atom types.  And, perhaps
>we need only have a list of "check these other force fields before
>choosing".  But, it might be nice, for this and other reasons, to have a
>central list of type names, the places where they are used and what they
>are used for.
>
>:-) Lachele
>
>Dr. B. Lachele Foley
>Complex Carbohydrate Research Center
>The University of Georgia
>Athens, GA USA
>lfoley.uga.edu
>http://glycam.ccrc.uga.edu
>
>________________________________________
>From: Yong Duan [duan.ucdavis.edu]
>Sent: Sunday, December 11, 2011 11:50 AM
>To: AMBER Developers Mailing List
>Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type
>work around
>
>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
>530-754-7632
>
>
>
>
>
>
>On 12/10/11 10:26 AM, "B. Lachele Foley" <lfoley.uga.edu> 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
>>overwhelmed.
>>
>>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
>>lfoley.uga.edu
>>http://glycam.ccrc.uga.edu
>>
>>________________________________________
>>From: case [case.biomaps.rutgers.edu]
>>Sent: Saturday, December 10, 2011 9:24 AM
>>To: amber-developers.ambermd.org
>>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 www.glycam.org/params 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
>>eliminates
>>the need for this workaround?
>>
>>...thanks!....dave
>>
>>
>>_______________________________________________
>>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
>
>
>
>_______________________________________________
>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
_______________________________________________
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
Received on Sun Dec 11 2011 - 15:30:03 PST
Custom Search