jungfrauandClaude Opus 5
8ea3076f96
Four passes over all ten million partials and one over all four million fulls, each of them a single thread walking a fat struct: the snapshot of corr taken before the pass filters, the zeta filter, the frame rejection, the extraction of corr for the upload, and the scatter of the downloaded fulls arrays back into Obs. All are independent per element, so all are chunked now, and the split is gated on the amount of data rather than the core count. Measured on the heaviest crystal, summed over the run: corr snapshot 0.14 s -> 0.05, zeta filter 0.20 -> 0.04, corr upload 0.16 -> 0.07, fulls scatter 0.27 -> 0.06. Two things were tried in the same phase and are NOT here, both measured on the way past. Spreading the combine over the other three GPUs: the whole gpu_->Combine() call is 1.27 s over the entire run, so four cards could save about a second at best, but the partials would have to live on every device - 1.7 GB of transfer at the 1.5 GB/s this machine gets - and the fulls would have to be gathered back for the merge, which reads them where they are. The replication alone costs more than the best case saves. And staging the fulls download through a page-locked block, which reads like the textbook fix for copies running at 1.5 GB/s, measured 0.76 s -> 0.80 s: whatever limits them here, it is not the driver's bounce buffer. Battery 9m23s, space group 21/24, no failures; the crystals that moved are the two already known to sit on knife edges. 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.