leonarski_fandClaude Opus 5 92a615085d grid scan: the snake reverses on the acquisition row, not the display row
GetElementPosFast_step took the snake parity from GetElementPosSlow_step,
which is the DISPLAY row: it is the acquisition row r = image / n_fast,
flipped to (n_slow-1) - r when the slow step is negative. So for a negative
slow step the parity it hands back is parity(n_slow-1) XOR parity(r), and
with an even n_slow that is inverted on every row - the whole raster comes
out mirrored along the fast axis. An odd n_slow leaves it correct, so the
same scan collected with 20 or 25 images disagreed about where image 0 sat:
n_fast=5, fast +1.5 um, slow -2.5 um, snake on gives images 0..4 at fast
index 4,3,2,1,0 with 4 rows and 0,1,2,3,4 with 5 rows. A positive slow step
was correct at both counts, and so was every non-snake configuration.

Snake means the stage reverses direction on alternate rows in acquisition
order, so the parity has to come from the acquisition row. Taking it from
image_number / n_fast directly makes the fast index independent of the slow
axis and of the row count, and drops the call into the display-row function
that caused the coupling. vertical_scan only relabels which axis is fast, so
it was wrong in exactly the same way and is fixed by the same line.

Affected files: written by an affected build, with snake on, a negative
grid slow step (step_y for a horizontal scan, step_x for a vertical one),
and an even number of rows. Their /entry/sample/transformations/grid_scan_x
or _y is mirrored along the fast axis, as was the grid map in the frontend
and the viewer - both mirrored together, which is why neither showed it.

Tests: the interaction of snake with the step signs was never asserted, only
each in isolation, so add a table over snake x {+,- fast step} x {+,- slow
step} x {even, odd row count} x {horizontal, vertical} asserting positions,
plus a case running one affected configuration through GetXContainer_m /
GetYContainer_m and Rearrange. Every pre-existing assertion is unchanged and
still passes; only the four negative-slow, even-row cells of the product
move.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EFEJG6WBQv8th4UJFNe53N
2026-09-02 10:57:15 +02:00
2026-08-26 22:47:00 +02:00
2026-08-13 17:03:10 +02:00
2026-08-25 08:21:39 +02:00
2026-08-26 22:47:00 +02:00
2026-08-31 09:11:22 +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-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-27 22:16:54 +02:00
2026-08-13 17:03:10 +02:00
2026-08-31 09:11:22 +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%