Rotating Bunge Euler Angles in the Order XYZ Using Matrix Multiplication

[Neta1403]

Hello,

I'm using MTEX in my code to generate pole figures from Euler angles. First, I would like to express my sincere appreciation for the MTEX code. It is a very powerful and useful tool!
code_summery_and_results.pdf

I’m trying to write a piece of code which rotates a file of orientations that are given as Bunge (“ZXZ”) Euler angles first around the X axis (east-west), then around Y (inside and outside of the screen) and finally around the Z axis (north-south). Note that the angles to rotate are given as ZXZ but the rotation itself should be in the order XYZ.
The function should be used as follows:

rotate_XYZ_V2(orig_EA_file, angle1,angle2,angle3);

Where angle1 corresponds to the amount of rotation around the X axis, angle2 corresponds to the amount of rotation around the Y axis, and angle 3 corresponds to the amount of rotation around the Z axis. These angles are given in degrees.

I went over each orientation from the file, converted it to its’ equivalent matrix representation R_orig and then multiplied it by the rotation matrix which corresponds to angle1, angle2 and angle3, assuming they are given in the order “XYZ”. To convert each orientation to its corresponding matrix representation, I used angle2dcm (from the Aerospace toolbox) which follows the ZXZ convention. To create the rotation matrix, I used eul2rotm as follows:

Rx = eul2rotm([0 angle1 0], 'XYZ'); %rotates correctly
Ry = eul2rotm([0 angle2 0], 'XYZ'); % does NOT rotate correctly
Rz = eula2rotm([0 0 angle3], 'XYZ'); %rotates correctly
R=RzRyRx;

Note that the argument position in the above calls does not always match the axis position (for example, angle1 is the second argument in the call to eul2rotm even though the first rotation is around X. This is because for some reason, calling eul2rotm with the angles positioned that way produced best results so far. At first, I tried switching the order because I thought that there might be a mismatch between the convention I use (X-east-west, Y-depth, Z-north-south) and that of matlab (X-east-west, Y-north-south, Z-depth) – however, as can be seen in the calls, the mismatch in the argument position is not simply a matter of switching between the argument position of angle2 and angle3 (that is, putting angle2 as a 3rd argument and angle3 as a second argument while leaving angle1 as the first argument does not solve the problem but rather causes a rotation around Z to be interpreted as a rotation around X, a rotation around X and around Y to be interpreted as a rotations around Z).
Also note that simply calling the function like this:

Rx = eul2rotm([angle1 angle2 angle3], 'XYZ');

works for rotations around Z only, but not for X (for some reason, using a rotation matrix that was created by multiplying 3 separate rotation matrices for each axis works for X as well, but still not for Y).

In the end of the procedure, I convert the resulting matrix back to euler angles using dcm2angle. Note I made sure to convert to radians and degrees to match the signature of the functions used.

To test my function, I plot pole figures which correspond to the amount of rotation. However, what I notice is that rotation around Y is interpreted as a rotation around X (starting from the original, unrotated orientation) and sometimes around Z (for example, after having already rotated around Z).

I’ve attached a pdf file that contains a schematic of my code as well as the pole figures resulting from the angles generated by rotate_XYZ for different 90 degree rotations (starting with a 90 degree around X and Z and then adding 90 degrees around the remaining two axes). In the results, correct results are colored in green and wrong ones in red.

Any advice would be appreciated.

Thanks,

Neta

[zmichels]

Are most of your rotations going to be simple one-axis rotations of 90° as shown in your example? If so, maybe it'd be easier or less-confusing to use something like

rotation('axis', xvector, 'angle', 90°)

You could also concatenate multiple of these single rotations to get what you need. I don't think such an approach is necessary, but I admit I have a hard time following exactly your situation of data, especially confused by having ZXZ eulers yet choosing to rotate them out of order. But anywhooo... maybe a simpler/different approach to rotations would be a tractable starting point(?). MTEX has a handful of ways to specify a rotation/orientation.

[zmichels]

Also... forgot to ask... have you checked that the XYZ axes are aligned to the page the way you intend? For example, I use a default arrangement in which Z is through the page and Y is North-South... but you described an opposite scenario. You probably already checked, but if not, would be good to confirm is aligned how you expect before you proceed.
You can visualize cwhere each point by plotting them individually, and you can access them with:

vector3d.X
vector3d.Y
vector3d.Z

[Neta1403]

Thank you very much for your quick, kind and detailed response. It's an honor to receive an email from someone like you!

Not all of my rotations are simple 90 degree rotations but I started with those because it is easier to check the results. I tried setting the axes alignment like so:

setMTEXpref('xAxisDirection','east')
setMTEXpref('zAxisDirection', 'north')
setMTEXpref('yAxisDirection', 'outofPlane')

However, when I plot the vectors (using plot(vector3d.X, 'label', 'X')for example) I see that while X is indeed east-west but Y is north and Z is not plotted.

Another approach I tried is simply using MTEX rotation.byAngle instead of implementing the rotation myself, however that doesn't work either. The followingrotation, for example, is supposed to rotate around Y, however when I plot its corresponding pole figure I see no change compared to the original pole figure:

file_path = fullfile(cfg.synthetic, 'processed_Synthetic_A type.dat'); % file containing 3 columns of euler angles
cs = crystalSymmetry('mmm', [4.756 10.207 5.98], 'mineral', 'Olivine', 'color', 'light blue');
ori = orientation.load(file_path, cs, 'ColumnNames', {'phi1', 'Phi', 'phi2'});
v=vector3d(0,1,0);
rot=rotation.byAxisAngle(v,pi/2);
new_ori = rot*ori;

In case there's any detail I might have missed I'd be glad to hear.
Thanks a lot!!!
Neta

[ralfHielscher]

You can set yAxisDirection out of screen if you would switch to MTEX 6.0. Would this been an option for you?

Ralf.

[Neta1403]

Thank you very much! I tried updating but when I plot the vectors (using plot(vector3d.X, 'label', 'X')for example) I still see that while X is indeed east-west but Y is north and Z is not plotted. That's the code I used: setMTEXpref('xAxisDirection', 'east'); setMTEXpref('zAixsDirection','north'); setMTEXpref('yAxisDirection','outofPlane'); vx=vector3d(1,0,0,"antipodal"); vy=vector3d(0,1,0,"antipodal"); vz=vector3d(0,0,1,"antipodal"); plot(vx,'label','X'); plot(vy,'label','Y'); plot(vz,'label','Z') Thanks again! Neta ‫בתאריך יום ד׳, 1 בינו׳ 2025 ב-11:53 מאת ‪Ralf Hielscher‬‏ <‪ ***@***.***‬‏>:‬

…

You can set yAxisDirection out of screen if you would switch to MTEX 6.0. Would this been an option for you? Ralf. — Reply to this email directly, view it on GitHub <#2287 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKPLGHGKDZ64T6FPUXDEWE32IO3KTAVCNFSM6AAAAABUNPUEE6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZQHE2DIOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>