(And someone really transformed the "TO" addresses here. Hmm, was that a right-hand or left-hand transformation?)
I've read Chapter 3 ("Euler Angles") of the book recommended by Anthony
(Rotations, Quaternions, and Double Groups, by Simon L. Altmann, 1986).
A masterfully readable work.I'm not convinced.
Here are some complications with using Euler Angles:
a) Euler rotation sequences are "always defined in terms of
post-multiplying the row basis which they form." Close inspection of the
text indicates that this means a sequence Rz1 then Ry then Rz2 in "Euler"
convention is in matrix form Rz2*Ry*Rz1. This is opposite the actual
internal transformation matrix convention of Jmol. Not to say that
it can't be implemented, but one must be careful in the implementation, because
our internal transformation matrix involves a different convention. This isn't a problem for the user, just Miguel.
b) As Anthony pointed out, there are two Euler conventions, RzRxRz and RzRyRz. Of these, Altmann uses RzRyRz and justifies it by saying: "older definitions in which the second rotation is taken around x do not agree with current angular momentum conventions." So I wouldn't immediately conclude that we should use RzRxRz.
c) Euler angle rotation is not defined the way "rotate" is defined
in Rasmol, Chime, and Jmol. Call it the fault of the chemists. Whatever.
But +90 Rasmol/Chime/Jmol is -90 Euler. This is because the angles
are defined in terms of changing the coordinate system, not the points
in space. Of course, the Jmol user is not interested in anything except
rotating points in space. So output of the "official" Euler angles
would all be opposite what one would use in "rotate {x|y|z}" commands.
Obviously (I think) we want to output the numbers that would be used
in "rotate" commands, not their inverses. In fact, I would even suggest
that the output format should be in command format:"rotate x 34.5; rotate y 46.7; rotate z 123.0"
or
"rotate z 34.5; rotate y 46.7; rotate z 123.0"
Euler or not, this should be absolutely crystal clear what it means and can be parsed easily, if desired, with JavaScript:
R1 = parseFloat(Jmol.orientation().split(";")[0].split(" ")[2])
R2 = parseFloat(Jmol.orientation().split(";")[1].split(" ")[2])
R3 = parseFloat(Jmol.orientation().split(";")[2].split(" ")[2])or even just:
R1 = parseFloat(Jmol.orientation().split(" ")[2])
R2 = parseFloat(Jmol.orientation().split(" ")[5])
R3 = parseFloat(Jmol.orientation().split(" ")[8])d) As far as I can see, Jmol
rotate z 34.5; rotate y 46.7; rotate z 123.0
is
Euler -123.0, -46.7, -34.5
I think the way it works is that specifying the Euler angles would
tell the user how to RETURN the model to the default orientation. Useful perhaps, but not exactly the intuitive "show orientation"
e) From what I can tell, Anthony, your initial objection to using RxRyRz was based on Altmann's analysis of this as an inadequate representation. What Altmann actually says is: "The solutions...are, at best, two-valued and they can be entirely undetermined..." Well, actually, that's not quite true. This statement makes it sound like RxRyRz allows for an arbtrary assignment of Rx and, from that, an assignment of Rz. But that doesn't really follow in practice. In determining RxRyRz from a transformation matrix, Ry is defined explicitly from one of the corner elements of the transformation matrix, which is siny or -siny, depending upon your definition of the matrix. From that, Rx and Rz are explicitly defined from other elements of the matrix based on atan2(y,x) PROVIDED cosy <> 0. In the case that cosy=0, then we are at precisely the same "dilema" as for Euler angles -- that with a 0 rotation about y (Euler) or a 90 rotation about y (RxRyRz), one can arbitrarily assign Rz = 0 and put all the rotation into the other axis. This is what the logic I presented earlier does. It isn't a dilema, really, it's a boon, because the user only needs to specify two rotations, not three, to generate the view.
f) [Boy, this is sounding harsh. I don't mean to be, but I also want to be very clear.] Altmann specifically says in this chapter, "The parameterization of rotations by the Euler angles is not without fault...because, for vanishing Beta (i.e., 0 rotation about y), Alpha and Gamma (i.e. last and first rotations about z) are undetermined, only their sum being significant." OK, in fact, this argument against using Euler angles is precisely the argument against rotations about orthogonal axes in general, including RxRyRz. One can't say Euler angles are "better" than RxRyRz based on this. It's just not true. Both have the same exact limitation.
My recommendation should make everyone happy:
show rotation --> "rotate x 31.5; rotate y 33.7; rotate z 13.0" (as previously described)
show euler --> "Rz=-123.0, Ry=-46.7, Rz=-34.5" (whatever suits Anthony)
show axisangle --> "axis=xxx yyy zzz, angle=ddd" (possibly very useful as well)
show moveto --> "moveto ................." (exact moveto command here--could be "show orientation")
In this way, someone might actually use Jmol to manipulate a structure and then get whatever they need for some completely other application.
Bob
Anthony Stone wrote:
What would the user want the information for? (Sorry if this has been explained before, but as I said I didn't follow the early part of this thread, and although I looked at the archive I may have missed something.)
I take it that the user might need the information to reproduce the same view again, or to drive some other program to produce the same view. In that case RxRyRz information would be useful only if JMol or some other program could understand it as input, and that seems unlikely. Jmol could presumably interpret 3 successive rotations, but in that case it would cope just as well with RzRxRz or RzRyRz. The transformation to Euler angles is singular if the rotation is around the z axis, so there are numerical problems if the rotation axis is close to the z axis, though in practice that can be handled as a special case. The advantage of the angle-axis representation is that it can be obtained straightforwardly from the rotation matrix via the quaternion representation.
If Euler angles are to be used, I would advocate RzRyRz, which is used in quantum mechanics and hence in most applications concerning molecules, rather than RzRxRz, which is mainly used in classical mechanics. But the relationship between them is very simple so it's not a big issue.
Anthony
At 08:54 on 5 October, Bob Hanson wrote:
> Miguel, we have this book at St. Olaf. I'll take a look.
> > Anthony, do you see any practical problems with delivering
> RxRyRz information to the user, or is this more of a concern
> in principle? Does it make any difference, since Jmol doesn't use
> RxRyRz for anything right now and wouldn't except for
> informing the user of a simple set of rotations that will
> generate one specific structure? Probably when output, these
> would be rounded to the nearest integer anyway.
> (Though I don't have Miguel's thoughts on that.)
> > No one is suggesting that Jmol use RxRyRz for representing arbitrary
> rotations internally.
> > Bob
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
