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