1eefd035c2c0c5659b37d7d948bd730bf195cc76
Build Packages / Unit tests (push) Successful in 1h53m42s
Build Packages / build:windows:nocuda (push) Successful in 14m4s
Build Packages / build:windows:cuda (push) Successful in 21m25s
Build Packages / build:viewer-tgz:cpu (push) Successful in 11m53s
Build Packages / build:viewer-tgz:cuda (push) Successful in 15m2s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 20m56s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 18m47s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 20m21s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 15m15s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 18m27s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 18m53s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 13m50s
Build Packages / DIALS test (push) Successful in 20m13s
Build Packages / XDS test (durin plugin) (push) Successful in 8m39s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 8m59s
Build Packages / XDS test (neggia plugin) (push) Successful in 9m2s
Build Packages / Generate python client (push) Successful in 29s
Build Packages / Build documentation (push) Successful in 1m21s
Build Packages / Create release (push) Skipped
Build Packages / build:rpm (rocky9) (push) Successful in 14m1s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 14m11s
Build Packages / build:rpm (rocky8) (push) Successful in 14m30s
The PONI export mapped the internal angles to pyFAI as (+rot1, -rot2, -rot3). Checked against pyFAI 2026.5.0 directly - building a Geometry from the exported values and comparing calc_pos_zyx against the lab position DiffractionGeometry computes, per pixel over the whole detector and with each angle exercised on its own - the correct mapping is (+rot1, -rot2, +rot3): it agrees to 1.4e-17 m, while negating rot3 puts a pixel 25 mm out on a rot3-only geometry. rot1 and rot2 were already right, which is consistent with how this was originally validated: a LaB6 powder image, where rings sharpened once the rot2 flip was applied. That check could not have caught rot3, because a rotation about the beam leaves q and 2theta invariant and moves only the azimuth - so the error only ever showed up in cake/sector integration, and only for a detector actually rotated about the beam. rot3 is never refined and has no CLI flag, so in practice it is almost always zero. The old comment derived the signs from "a reflection in y between the MX and pyFAI frames". That gives the right answer for rot1 and rot2 and the wrong one for rot3, and pyFAI's own documentation contradicts itself on the direction of its axis 2, so the comment now records the empirical pin instead of a derivation. Calibration_PoniFileAxisConvention previously set rot3 to zero and asserted Rot3 == 0.0 - the one cell that could not fail. It now uses a non-zero rot3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jungfraujoch
Application to receive data from the PSI JUNGFRAU and EIGER detectors.
All documentation is now placed in docs/ subdirectory and for the current version hosted on Jungfraujoch Read The Docs page.
Languages
C++
75%
HTML
7.8%
C
6.2%
TypeScript
4.3%
Cuda
2.3%
Other
4.3%