Skip to content

Record that 2-BM's start_date is the previous scan's end_date - #653

Merged
xmap merged 1 commit into
mainfrom
worktree-2bm-timestamp-docs
Aug 12, 2026
Merged

Record that 2-BM's start_date is the previous scan's end_date#653
xmap merged 1 commit into
mainfrom
worktree-2bm-timestamp-docs

Conversation

@xmap

@xmap xmap commented Aug 12, 2026

Copy link
Copy Markdown
Owner

Folds today's beamline findings into the 2-BM pages. Docs only; no code.

start_date is the previous scan's end_date

Operations said start_date is the acquisition timestamp and stopped there, which is how a reader ends up trusting it. Measured across the six files in the pilot experiment folder: every end_date falls within five seconds of its own file close, and in three consecutive cases the start_date is the previous file's end_date to the second. test_005 ran on the morning of Aug 12 and claims a start on the evening of Aug 11.

One file, test_002, does look correct. It is included rather than omitted, because leaving it out would overstate the pattern and anyone checking their own files will find it.

The page separates measurement from inference. The six-file table and the live PV read are measured; the explanation (the areaDetector timestamp attribute refreshing only while frames flow) is a reading of them, and staff own the IOC configuration that would confirm or replace it.

New DATA-11 asks whether the file contract can be repaired at the source, and states plainly that this is upstream of CORA: every consumer of a 2-BM scan file inherits the wrong start time, silently.

DATA-8 becomes answerable

Until 2026-08-12 the question could not be asked at all. The reader could not read the commanded counts, because 2-BM writes them as one-element arrays and the reader understood only plain scalars, so every shortfall check silently compared against nothing. Fixed in #651. The first production scan CORA read end to end dropped no frames: 1501 commanded, 1501 captured.

Host section

The interim file-access answer is corrected from what was proposed to what was done: a staged copy, exercised on a 24.5 GB file, with the two costs a durable answer should weigh (the copy duplicates the file; digesting it takes 82 seconds, which is why the deployment raises the digest walk budget from #652).

🤖 Generated with Claude Code

Operations said `start_date` is the acquisition timestamp and stopped
there, which is how a reader ends up trusting it. Measured across the
six files in the pilot experiment folder: every `end_date` falls within
five seconds of its own file close, and in three consecutive cases the
`start_date` is the previous file's `end_date` to the second. One file
does look correct, which is part of why the defect survives casual
inspection.

The page now separates what was measured from what was inferred. The
six-file pattern and the live PV read are measurements; the explanation
(the areaDetector timestamp attribute refreshing only while frames flow)
is a reading of them, and staff own the IOC configuration that would
confirm or replace it. New DATA-11 asks whether the file contract can be
repaired at the source, and says plainly that this is upstream of CORA:
every consumer of a 2-BM scan file inherits it, silently.

DATA-8 gains its first real data point and, more usefully, becomes
askable at all. Until 2026-08-12 the reader could not read the commanded
counts, because 2-BM writes them as one-element arrays and the reader
understood only plain scalars, so every shortfall check compared against
nothing. The first production scan CORA read end to end dropped no
frames.

The host section's interim file-access answer is corrected from what was
proposed to what was done: a staged copy, exercised on a 24.5 GB file,
with the two costs a durable answer should weigh (the copy duplicates
the file, and digesting it takes 82 seconds).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Coverage report

This PR does not seem to contain any modification to coverable code.

@xmap
xmap merged commit 54a528c into main Aug 12, 2026
19 checks passed
@xmap
xmap deleted the worktree-2bm-timestamp-docs branch August 12, 2026 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant