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/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-developersReceived on Sun Dec 11 2011 - 15:00:02 PST