jungfrauandClaude Opus 5
f1dcfbe525
Build Packages / build:viewer-tgz:cpu (push) Successful in 20m3s
Build Packages / build:viewer-tgz:cuda (push) Successful in 22m56s
Build Packages / build:rpm (ubuntu2404_nocuda) (push) Successful in 24m26s
Build Packages / build:rpm (rocky9_nocuda) (push) Successful in 24m39s
Build Packages / build:rpm (ubuntu2204_nocuda) (push) Successful in 29m8s
Build Packages / build:rpm (rocky8_nocuda) (push) Successful in 29m27s
Build Packages / build:rpm (rocky8_sls9) (push) Successful in 29m32s
Build Packages / build:rpm (rocky9_sls9) (push) Successful in 20m30s
Build Packages / XDS test (durin plugin) (push) Successful in 11m34s
Build Packages / build:rpm (rocky9) (push) Successful in 21m31s
Build Packages / Generate python client (push) Successful in 36s
Build Packages / Build documentation (push) Successful in 1m6s
Build Packages / Create release (push) Skipped
Build Packages / build:rpm (rocky8) (push) Successful in 26m10s
Build Packages / build:rpm (ubuntu2204) (push) Successful in 26m14s
Build Packages / build:rpm (ubuntu2404) (push) Successful in 21m48s
Build Packages / DIALS test (push) Successful in 21m36s
Build Packages / XDS test (neggia plugin) (push) Successful in 10m13s
Build Packages / XDS test (JFJoch plugin) (push) Successful in 11m8s
Build Packages / build:windows:nocuda (push) Successful in 1h1m46s
Build Packages / Unit tests (push) Successful in 1h19m54s
Build Packages / build:windows:cuda (push) Successful in 1h3m24s
Writing an image to the process file takes the global HDF5 mutex, which is the same one every worker needs to find its next image. The write is short - the file holds the per-image analysis, not the pixels - but with a worker per hardware thread they were still taking turns at it. The workers now post to a bounded queue and one thread owns the file. A DataMessage does not own its pixels, it points into the reader's buffer, so the raw image is parked in the queue beside its message; without that the worker frees the pixels on its next iteration and the writer reads whatever landed there. The queue is bounded at four per worker so a run whose analysis outpaces its writer cannot accumulate every image it has ever processed, and a write that throws - out of space, above all - is held and rethrown when the loop drains it, before the end message is written and the file finalized. Worth 6.8 s -> 6.5 s on a 16 Mpx rotation dataset at 48 workers, on top of the much larger gain from taking the read out of the same lock. Both process files, written with and without the writer thread, re-scale to the same 101215 unique reflections at the same ISa. Co-Authored-By: Claude Opus 5 <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.