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
Received on Fri Nov 18 2011 - 08:30:02 PST
