Re: [AMBER-Developers] Chirality routines in tleap; do they do the correct thing with coordination numbers >4

From: B. Lachele Foley <lfoley.uga.edu>
Date: Fri, 18 Nov 2011 23:19:46 +0000

Please find attached a lengthy leap input file containing a number of sample builds, good and bad, with comments. I used tleap from AT15 patched through fix #6 (no leap bugfixes after that) and visualized with VMD. I didn't try xleap. I haven't tried the most recent from the git repo, but I doubt that matters: I don't recall discussion of these issues before. Keep in mind that these are minimal examples -- they might be removed from the context where the particular series of commands seems reasonable. We usually encounter these things in much larger contexts. Some highlights: ### Here, the 0GA is changed from alpha (axial) to beta (equatorial) ### m = sequence {OME} b = sequence {0GA} set m tail m.1.O m = sequence {m b} saveamberparm m invert1.top invert1.rst ### We think this is also a chirality thing, just not ### at the anomeric center (this time). p = copy 0SA p = sequence { OME p } saveamberparm p copy-yes.top copy-yes.rst ### Order matters -- note red-shift (blue shift?) in angles.... ### m = sequence { OME 4GA 4GA 4GA 4GA 4GA 0GA } impose m {3 2} { {C2 C1 O4 C4 -40.0} } ## builds as -50 impose m {4 3} { {C2 C1 O4 C4 -50.0} } ## builds as -60 impose m {5 4} { {C2 C1 O4 C4 -60.0} } ## builds as -70 impose m {6 5} { {C2 C1 O4 C4 -70.0} } ## builds as -80 impose m {7 6} { {C2 C1 O4 C4 -80.0} } ## builds as -80 saveamberparm m imp_shift.top imp_shift.rst :-) 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: B. Lachele Foley [lfoley@uga.edu] Sent: Friday, November 18, 2011 11:00 AM To: AMBER Developers Mailing List Subject: Re: [AMBER-Developers] Chirality routines in tleap; do they do the correct thing with coordination numbers >4 I can provide minimal, reproducible examples of the problems we saw. But, it will take me a few hours. Do you prefer it sent here or as a series of bug reports? BTW: one reason we hadn't said anything before was because support for tleap had stopped. It seemed pointless to complain. We never quite got around to these things with sleap, tho we did note that sleap seemed to inherit some similar behaviors from tleap. BTW(2), in all the cases I know of right now, it isn't the entire molecule being reflected. It's only one chiral center being inverted. :-) 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: David A Case [case@biomaps.rutgers.edu] Sent: Friday, November 18, 2011 9:20 AM To: AMBER Developers Mailing List Subject: Re: [AMBER-Developers] Chirality routines in tleap; do they do the correct thing with coordination numbers >4 On Fri, Nov 18, 2011, Josh Berryman wrote: > Can't reproduce I'm afraid; just a quick test of reflections on an Alanine > seems to give consistent results tleap to xleap. Possibly its fixed now, > has anyone modified tleap/xleap since AMBER 8? Sure...but tleap and xleap have always shared the code for all commands; xleap just has some extra code to do the visual stuff. So I was surpised at reports of differences. I agree that the way LEaP adds missing atoms can be quite strange. An example that hit us recently: if you have a valine residue where the CG1 and CG2 atoms are reversed (and hence have the wrong chirality), LEaP will build a missing HA atom in a bad place, which upon minimization can lead to a D- amino acid. Now one could say garbage in == garbage out, but few people would expect errors in the side chain names to affect how a backbone hydrogen is added to structure. So the algorithm used might benefit from a re-thinking. And I'm not at all surprised that LEaP has trouble adding the oxygen to a heme group. A comment about "impose": here the whole syntax is really wrong: if you want to change a torsion, you need to tell the code not only what the final torsion should be, but which atoms should be moved in order to achieve that goal -- (see the rot4() and transformmol() functions in NAB). The LEaP "impose" command leaves out the second part, and tries to guess which atoms to move. This is often the natural choice that the user wants, but can fail or be counter-intuitive, such that trial and error is required to figure out what the result will be. Fixing this is left as an exercise for the reader. ...dac _______________________________________________ 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 Fri Nov 18 2011 - 15:30:02 PST
Custom Search