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