mx/Jungfraujoch
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 72 Wiki Activity

Name the right rotation in the NXmx frame comment

Browse Source 
The comment said internal-to-McStas is 180 degrees about x. It is 180 degrees
about z: internal (a,b,c) maps to McStas (-a,-b,+c), which is what makes the
written vectors correct - internal +y becomes (0,-1,0), the -x of Rx(-rot2)
becomes (1,0,0), and the -z of Rz(-rot3) is unchanged.

180 degrees about x is the internal-to-imgCIF relation, one step further on, and
it is the frame the verification was done in - which is why the vectors are right
and only the prose was wrong. Re-measured after the change: still 1.6e-6 mm over
nine tilt settings.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
leonarski_f
2026-08-22 22:33:30 +02:00
co-authored by Claude Opus 5
parent 7039aa4e45
commit cc334c5c55
1 changed files with 5 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
writer/HDF5NXmx.cpp
+5 -2
View File
@@ -665,8 +665,11 @@ void NXmx::Metrology(const StartMessage &start, const EndMessage &end) {
// Jungfraujoch holds the tilt in the PyFAI PONI convention, poni_rot = Rz(-rot3)*Rx(-rot2)*Ry(+rot1)
// (DiffractionGeometry::UpdatePoniRotMatrix), written in the internal frame: x along increasing
// column, y along increasing row, z along the beam. NXmx uses McStas, which is that frame turned
// 180 degrees about x - a proper rotation, not a mirror - so rotations about y and z reverse sense
// while those about x keep it. Hence the axis vectors below. A depends_on chain applies the
// 180 degrees about z - a proper rotation, not a mirror - so rotations about x and y reverse sense
// while those about z keep it. Hence the axis vectors below: internal +y becomes (0,-1,0), the
// -x of Rx(-rot2) becomes (1,0,0), and the -z of Rz(-rot3) is unchanged. (Do not confuse this
// with the internal-to-imgCIF relation, which IS 180 degrees about x - that is the frame DIALS
// reports in, one step further on.) A depends_on chain applies the
// DEEPEST dependency first, so rot3 sits at the root to make the product R_rot3*R_rot2*R_rot1.
SaveScalar(transformations, "rot1", rot1)->
Transformation("rad",