leonarski_fandClaude Opus 5
28cb185325
Build Packages / build:windows:nocuda (push) Successful in 13m32s
Build Packages / build:windows:cuda (push) Successful in 19m31s
Build Packages / build:viewer-tgz:cpu (push) Successful in 14m55s
Build Packages / build:viewer-tgz:cuda (push) Successful in 15m55s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 16m59s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 19m21s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 15m57s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 20m48s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 21m1s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 18m38s
Build Packages / build:rpm (rocky8) (push) Successful in 20m31s
Build Packages / build:rpm (rocky9) (push) Successful in 18m45s
Build Packages / XDS test (durin plugin) (push) Successful in 9m43s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 21m22s
Build Packages / Generate python client (push) Successful in 13s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 15m16s
Build Packages / Create release (push) Skipped
Build Packages / Build documentation (push) Successful in 51s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 7m17s
Build Packages / DIALS test (push) Successful in 17m34s
Build Packages / XDS test (neggia plugin) (push) Successful in 6m10s
Build Packages / Unit tests (push) Successful in 1h22m42s
XDS is never handed this geometry - the durin plugin gives it image data only
(plugin_get_header returns dimensions, bytes per pixel, pixel size and frame
count, nothing more) and XDS refines its own from XDS.INP. That is exactly what
makes printing ours in the same convention useful: it turns "does our geometry
agree with XDS's refinement" into reading two logs side by side.
The two laboratory frames already coincide - x along increasing detector column,
y along increasing row, z along the beam - so nothing is converted. XDS places a
pixel at
x_lab(i,j) = (i-ORGX)*QX*X_axis + (j-ORGY)*QY*Y_axis + DISTANCE*(X_axis x Y_axis)
which is DiffractionGeometry::LabCoord with X_axis = poni_rot*(1,0,0) and
Y_axis = poni_rot*(0,1,0). The axes are taken as differences of LabCoord so they
track whatever the geometry currently is, tilt included, and a tilt goes out as
the two axis vectors rather than as angles - the form XDS itself reports after
refinement.
Two traps are handled and documented: ORGX/ORGY are 1-based, XDS counting pixels
from 1 where we count from 0; and they are the PONI, the foot of the
perpendicular from the crystal, which is what our beam centre is too but is not
the direct beam once the detector is tilted.
ROTATION_AXIS is printed as stored. The direction is right, the frames being
shared, but its sign has not been cross-checked against an XDS refinement, so a
flip there should be read as unconfirmed rather than as a real disagreement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
