as a heads up, we'll have some extra atom types in the upcoming ff99SB
modification to side chains. It won't be a problem to avoid overlap as long
as we all know what's already used.
cheers
carlos
On Mon, Dec 12, 2011 at 12:41 PM, 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
Received on Mon Dec 12 2011 - 11:00:02 PST
