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

From: B. Lachele Foley <lfoley.uga.edu>
Date: Mon, 12 Dec 2011 20:54:11 +0000

He asked for a direct link to the bits to read. I know parts of this list go to the internet, but I don't think all of it does. Does it all? Is there a link? If not, that's ok -- not asking to post it. I'll get the info to him some other way.

:-) 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: Monday, December 12, 2011 1:27 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type work around

B. Lachele Foley, can you please ask Rob comment on this?

Thank you!

--
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/12/11 10:22 AM, "Yong Duan" <duan.ucdavis.edu> wrote:
>
>That's wonderful.
>
>
>Has anybody else published a paper claiming any other combinations? Just a
>check.
>
>Now, we have published papers claiming, as it stands, that GLYCAM will use
>two upper-case letters. GAFF has been using two lower-case letters. Let's
>assume that we are lucky that nobody else has claimed the remaining
>combination, all we need is to change all other amber ff to accommodate
>these. Is this what we plan to do?
>
>I propose a halt on this kind of quick claims based on whatever the
>reason, until we sort out this issue systematically so that we can have a
>coherent plan to move forward.
>
>Accommodating is a two-way street. As far as I know, a simple note in the
>parmxx.dat/frcmod.xx file allows easy conversion between what's published
>on paper and what is really happening in the file.
>
>--
>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/12/11 9:41 AM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
>
>>I have 'claimed' lower case first letter, upper case second letter for
>>the
>>Lipid 11 force field with the following atom types:
>>
>>AMBER Lipid 2011 Force Field (v1.0), A.Skjevik, B. Madej, K.Teigen &
>>R.C.Walker
>>cC 12.01                             carbonyl sp2 carbon (GAFF c -)
>>cB 12.01                             aliphatic sp2 carbon (GAFF c2-)
>>cA 12.01                             sp3 carbon (GAFF c3-)
>>oC 16.00                             sp2 oxygen with one connected atom
>>(e.g
>>C=O, COO-) (GAFF o -)
>>oS 16.00                             sp3 oxygen in ethers and esters
>>(GAFF
>>os-)
>>oP 16.00                             sp2 oxygen with one connected atom
>>(e.g
>>P-O) in phosphate group (GAFF o -)
>>oT 16.00                             sp3 oxygen bonded to carbon in
>>phosphate group (GAFF os-)
>>oH 16.00                             sp3 oxygen in hydroxyl group (GAFF
>>oh-)
>>nA 14.01                             sp3 N with four connected atoms
>>(GAFF
>>n4-)
>>pA 30.97                             phosphorus with four connected
>>atoms,
>>such as O=P(OH)3 (GAFF p5-)
>>hA 1.008                             H bonded to aliphatic carbon without
>>electrwd. group (GAFF hc-)
>>hE 1.008                             H bonded to aliphatic carbon with 1
>>electrwd. group (GAFF h1-)
>>hX 1.008                             H bonded to C next to positively
>>charged group (GAFF hx-)
>>hB 1.008                             H bonded to aromatic carbon (GAFF
>>ha-)
>>hN 1.008                             H bonded to nitrogen (GAFF hn-)
>>hO 1.008                             H in Hydroxyl group (GAFF ho-)
>>cR 12.01                             sp3 carbon - in Inositol ring
>>(GLYCAM
>>CG-)
>>cP 12.01                             sp3 C bonded to an O bonded to a P -
>>in
>>Inositol Ring (GLYCAM CP-)
>>oR 16.00                             O hydroxyl group - in Inositol Ring
>>(GLYCAM OH-)
>>hR 1.008                             H hydroxyl group - in Inositol Ring
>>(GLYCAM HO-)
>>hS 1.008                             H aliph. bond. to C with 1 electrwd.
>>groups - in Inositol Ring (GLYCAM H1-)
>>oO 16.00                             sp2 oxygen with one connected atom
>>(e.g
>>COO-) in head group (GAFF o -)
>>
>>These are described in the paper that is in review so too late to change
>>them now.
>>
>>We probably just need a document somewhere that describes all the atom
>>types
>>for the different force fields and allows people to see unused atom types
>>for example and essentially assign types to force fields as they are
>>used.
>>
>>The alternative is to prefix each atom type with the force field
>>description.
>>
>>E.g.
>>
>>99SB-CA
>>
>>But this will need some substantial reworking of the code and
>>modification
>>to all the force field files etc. Certainly not impossible for someone
>>who
>>is good at scripting things but probably too big a change to consider for
>>AMBER 12.
>>
>>All the best
>>Ross
>>
>>> -----Original Message-----
>>> From: B. Lachele Foley [mailto:lfoley.uga.edu]
>>> Sent: Sunday, December 11, 2011 1:16 PM
>>> To: AMBER Developers Mailing List
>>> Cc: Xiaocong Wang; Matthew Tessier
>>> Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type
>>> work around
>>>
>>> I wasn't thinking Wiki.  I was thinking dedicated table in the /doc
>>> section that is referenced from the AmberTools manual (or even an
>>> appendix to the manual).  I think all of the users would appreciate
>>> being able to easily look up atom types.  And, if we do that, it's easy
>>> for everyone to find and use, and they have to update the table in the
>>> documentation, so they have to see.
>>>
>>> :-) 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: Jodi Ann Hadden [jodih.uga.edu]
>>> Sent: Sunday, December 11, 2011 3:58 PM
>>> To: AMBER Developers Mailing List
>>> Cc: Xiaocong Wang; Matthew Tessier
>>> Subject: Re: [AMBER-Developers] [AMBER] ATTN GLYCAM users: CY atom type
>>> work around
>>>
>>> So this problem is relatively easy to fix -- one of us just has to
>>> change our CY atom type to a different 2-letter code. Our hesitation
>>> for that someone to be us is that GLYCAM-06 was published with atom
>>> type CY, that is the 2-letter code "CY" and all its associated
>>> parameters are literally laid out in tables in the GLYCAM-06 paper.
>>> It's not listed anywhere in the parm99 paper, which is apparently when
>>> it was first actually used on the protein side.
>>>
>>> This brings us to the bigger problem:  As our existing FFs expand and
>>> new ones are developed, we need to be extra careful to avoid atom type
>>> overlaps so that FFs that are intended to work together to parameterize
>>> mixed systems can actually be used this way. We now have AMBER FFs for
>>> proteins, carbohydrates, lipids, DNA, small/drug molecules, all of
>>> which could theoretically be used in combination, yes?
>>>
>>> The only atom type standard I'm aware of right now is that GAFF atom
>>> types are all lower case so that they never overlap with protein, etc.
>>> atom types, which are all upper case. Maybe it is useful going forward
>>> to extend standards to other FFs based on the class of molecules they
>>> parameterize. So proteins get all upper case (XX), GAFF gets all lower
>>> case (xx), then maybe as per Yong's suggestion, carbohydrates get upper
>>> first, lower second (Xx) and then maybe lipids get lower first, upper
>>> second (xX), etc. Something like that. Perhaps even numbers in one
>>> column or even in some cases symbols? Or perhaps extend atom types to
>>> 3-letter codes instead of 2? Just sort of just scheming out loud
>>> here...
>>>
>>> Anyway, molecule class specific atom type standards would just make
>>> everything straightforward and convenient for everyone because, when
>>> you develop your FF, you can choose whatever atom type codes you want
>>> as long as they match the appropriate molecule class format (XX, xx,
>>> Xx, xX, etc.) Mixed systems that combine different FFs for different
>>> classes of molecules no longer have to worry about overlaps in atom
>>> type because each molecule class has its own atom type format standard.
>>> It doesn't matter if two FFs for the same molecule class overlap
>>> because you wouldn't mix those. Does that make sense?
>>>
>>> The best part is that it avoids the communication lapses that lead to
>>> issues like the current one with CY where we have to go about
>>> organizing a wiki or something and call dibs on 2-letter codes, which
>>> are already very limiting even with case sensitivity. Not to mention
>>> the problem just crops up again every time you want to add a new atom
>>> type to your FF, you have to go to this theoretical wiki and see if the
>>> atom type is taken (and hope that the wiki's info is accurate and up to
>>> date) or you have to go fishing around in .dat files or mailing the
>>> list etc. and because everyone is so busy, communication lapses
>>> continue to happen and we end up eventually with another CY fiasco.
>>>
>>> Ok, so there is my idea. I'm now going to throw Xiaocong under the bus,
>>> because as our resident FF dev, he is supposed to be organizing
>>> resolution of this CY issue. I don't think he's actually on the dev
>>> list, so I'm CCing him to get him in on the conversation. With the
>>> developers meeting coming up, this seems like something worth getting
>>> the discussion started on -- What to do about CY and how to avoid this
>>> problem in the future.
>>>
>>> Jodi
>>>
>>>
>>> On Dec 11, 2011, at 12:52 PM, B. Lachele Foley 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
>>
>>
>>_______________________________________________
>>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 Mon Dec 12 2011 - 13:00:02 PST
Custom Search