Custom Search
-- 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-developersReceived on Mon Dec 12 2011 - 10:30:04 PST