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

Set the azimuthal reference in the .poni file

Browse Source 
An image integrated in pyFAI through our .poni came out with every chi 180 degrees from where it
belongs. pyFAI's in-plane axes are the negatives of ours, so Rot3 needs a half turn on top of the
sign flip. Being a rotation about the beam it leaves 2theta alone - which is why radial integration
was right all along and only the azimuth was wrong, and why a powder-ring check could never have
caught it.

The half turn is needed for the orientation-3 form written before rc.162 as well, so it is not an
artefact of declaring the orientation - the file has been 180 degrees out for as long as it has been
written.

Verified against pyFAI 2026.5.0 on a tilted detector with an off-centre beam, against the lab
positions of the NXmx chain: 2theta to 3.6e-15 deg and chi to 2.8e-14 deg. Then end to end, by
integrating an image in jfjoch's own layout through a .poni the code actually writes: chi lands
within 0.15 deg of physical truth on a 0.5 deg cake bin.

Withdraws two changelog claims. The .poni does negate Rot3, and declaring orientation did not fix
the azimuth: pyFAI's orientation is numerically inert here, so the file was relabelled and not
corrected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VfYvJT5Nb71suJCowRBn5z
This commit is contained in:
leonarski_f
2026-08-23 11:00:42 +02:00
co-authored by Claude Opus 5
parent ce11cade84
commit c1b6030c4f
4 changed files with 29 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/CalibrationTest.cpp
+9 -7
View File
@@ -111,15 +111,17 @@ TEST_CASE("Calibration_PoniFileAxisConvention", "[DetGeomCalib]") {
== Catch::Approx((x.GetYPixelsNumConv() - 1 - 1275 + 0.5) * pixel_m)); // slow axis = y
CHECK(std::stod(keys["Poni2"]) == Catch::Approx(1000.5 * pixel_m)); // fast axis = x
CHECK(std::stod(keys["Distance"]) == Catch::Approx(0.150));
// With orientation declared, (Rot1, Rot2, Rot3) = (+rot1, +rot2, -rot3): a row flip is improper,
// so it reverses rotations about x and about the beam and leaves the one about the vertical.
// Pinned against pyFAI 2026.5.0 - an exhaustive search over all four orientations, both Poni1
// anchorings and all eight sign combinations found exactly two exact solutions, this one and the
// unlabelled orientation-3 form written before. Do not "fix" these signs without repeating that
// search: a powder-ring check cannot test rot3, which moves only the azimuth.
// With orientation declared, (Rot1, Rot2, Rot3) = (+rot1, +rot2, -rot3 + pi): a row flip is
// improper, so it reverses rotations about x and about the beam and leaves the one about the
// vertical, and the half turn sets the azimuthal reference - pyFAI's in-plane axes are the
// negatives of ours, so without it every chi is 180 degrees out. Being a rotation about the
// beam it leaves 2theta alone, which is why radial integration was right while the azimuth was
// not. Pinned against pyFAI 2026.5.0 on a tilted detector, against the lab positions of the
// NXmx chain: 2theta to 3.6e-15 deg and chi to 2.8e-14 deg. Do not "fix" these without
// repeating that check - a powder-ring test cannot see rot3, which moves only the azimuth.
CHECK(std::stod(keys["Rot1"]) == Catch::Approx(0.01));
CHECK(std::stod(keys["Rot2"]) == Catch::Approx(-0.02));
CHECK(std::stod(keys["Rot3"]) == Catch::Approx(-0.03));
CHECK(std::stod(keys["Rot3"]) == Catch::Approx(-0.03 + PI));
CHECK(std::stod(keys["Wavelength"]) == Catch::Approx(geom.GetWavelength_A() * 1e-10));
// max_shape is [rows, cols] - the same slow-then-fast order as Poni1/Poni2.
const std::string shape = "[" + std::to_string(x.GetYPixelsNumConv()) + ", "