leonarski_fandClaude Opus 5 92ad304f15 rugnux: fail on an exhausted GPU instead of dropping the images it could not process
A per-image worker caught every std::exception and continued to the next image. That is right for
one undecodable image and wrong for a resource fault: a CUDA out-of-memory says nothing about the
image that happened to be in flight and everything about the machine, and it recurs on the next one.
The run therefore logged an error per image, skipped each of them, and exited 0 with a dataset that
was silently short - the merged numbers all moved, and nothing in the exit code or the summary said
so. Observed with several processes sharing one card: two arms of the same comparison lost 21 and 15
images, by different amounts, so the arms no longer saw the same data.

IsFatalResourceError rethrows for std::bad_alloc and for a JFJochException of category GPUCUDAError
or MemAllocFailed, and every per-image catch consults it first. There are ten of them, not the three
the obvious grep finds: besides the analyze/integrate/load sites in the two image loops, the
first-pass spot read swallows the same way at Warning severity, the pre-scan swallows it in three
places, and one geometry-refinement site caught it with no log line at all. The first-pass one
matters most - those frames build the reciprocal-space cloud the indexer runs on, so losing them
thins the input that decides whether the crystal indexes, and it does not change IMAGES_PROCESSED,
so a frame-count audit cannot see it.

Every one of these loops joins with future::get() or ParallelFor's RunTasks, both of which hold the
first exception and rethrow it at the join, so the throw propagates and nothing terminates.
JFJochException gained a Category() accessor for the test.

Verified by squeezing the card to 804 MB free and running at -N 4: the run now exits 1 with zero
dropped-image lines, where the same test on the previous binary produced the silent skips above.
The broker and receiver paths are deliberately untouched - dropping a frame is the better failure
there than killing a live acquisition.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lc5JG6kJqZoCWaoZ43JGTW
2026-08-29 14:58:04 +02:00
2026-08-26 22:47:00 +02:00
2026-08-13 17:03:10 +02:00
2026-08-27 22:16:54 +02:00
2026-08-25 08:21:39 +02:00
2026-08-26 22:47:00 +02:00
2026-08-27 22:16:54 +02:00
2026-08-25 08:21:39 +02:00
2026-08-27 22:16:54 +02:00
2026-08-27 22:16:54 +02:00
2026-08-27 22:16:54 +02:00
2026-08-27 22:16:54 +02:00
2026-03-26 20:50:33 +01:00
2026-06-23 20:29:49 +02:00
2026-08-27 22:16:54 +02:00
2026-07-19 09:39:28 +02:00
2026-08-26 22:47:00 +02:00
2026-08-27 22:16:54 +02:00
2026-08-26 22:47:00 +02:00
2026-06-13 21:27:41 +02:00
2026-06-23 20:29:49 +02:00
2026-08-25 08:21:39 +02:00
2024-11-22 21:25:20 +01:00
2026-08-25 08:21:39 +02:00
2026-08-26 22:47:00 +02:00
2024-12-02 21:17:14 +01:00
2026-08-13 17:03:10 +02:00
2025-10-25 22:05:47 +02:00
2026-07-03 19:18:56 +02:00
2026-06-23 20:29:49 +02:00
2026-08-13 17:03:10 +02:00
2024-12-02 21:17:14 +01:00
2026-08-25 08:21:39 +02:00
2026-08-26 22:47:00 +02:00
2026-08-25 08:21:39 +02:00
2026-08-26 22:47:00 +02:00
2026-08-27 22:16:54 +02:00
2026-08-13 17:03:10 +02:00
2026-08-27 22:16:54 +02:00

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.

S
Description
Jungfraujoch Data Acquisition System
Readme GPL-3.0
3 GiB
Languages
C++ 75.4%
HTML 7.5%
C 6%
TypeScript 4.2%
Cuda 2.2%
Other 4.6%