From 2378a8f680d077da712fd68041b273c6005b8dc2 Mon Sep 17 00:00:00 2001 From: Doga Gursoy Date: Mon, 22 Jun 2026 08:43:20 +0300 Subject: [PATCH] docs(2-bm): fold the vibration answers, drop the one-off baseline stubs (VIB-1..7) Staff settled the vibration / flat-field-stability questions (VIB-1 #265, VIB-2..7 #267): - VIB-1: the vibration measurement uses the SAME physical FLIR Oryx (serial 19173710) as the microscope camera 0, run in a high-frame-rate mode (~99 fps, 1000-frame stream), not separate hardware. Recorded as a note on the Camera descriptor entry. - VIB-2..7: the February 2026 vibration study (item_070) was a one-off, inconclusive investigation with no standing gates (the 100 mA value was incidental, no dominant source found, no calibrated flat-timing window). So CORA drops the Pending vibration_baseline Practice stub (deployments/aps/site.yaml) and the never-built vibration_baseline kind carve-out (test_procedure_kind_naming.py); no vibration Procedure or Caution is modeled. Removes the now-resolved "Vibration and beam stability" section from the 2-BM open-questions page (its table was already empty). Closes VIB-1 (#265) and VIB-2 through VIB-7 (#267). Co-Authored-By: Claude Opus 4.8 --- apps/api/tests/architecture/test_procedure_kind_naming.py | 7 +++---- deployments/2-bm/beamline.yaml | 7 +++++++ deployments/aps/site.yaml | 1 - docs/deployments/2-bm/questions.md | 7 ------- 4 files changed, 10 insertions(+), 12 deletions(-) diff --git a/apps/api/tests/architecture/test_procedure_kind_naming.py b/apps/api/tests/architecture/test_procedure_kind_naming.py index 9c6faa0a5a..cecedb235d 100644 --- a/apps/api/tests/architecture/test_procedure_kind_naming.py +++ b/apps/api/tests/architecture/test_procedure_kind_naming.py @@ -48,15 +48,14 @@ ) # Whole-kind carve-outs, with rationale: -# first_light - whole-system milestone, no single subject -# {dark,flat,vibration}_baseline - capture-and-store; the trailing noun is -# the produced artifact, not the operation +# first_light - whole-system milestone, no single subject +# {dark,flat}_baseline - capture-and-store; the trailing noun is the +# produced artifact, not the operation CARVE_OUT_KINDS = frozenset( { "first_light", "dark_baseline", "flat_baseline", - "vibration_baseline", } ) diff --git a/deployments/2-bm/beamline.yaml b/deployments/2-bm/beamline.yaml index 0e6b647baa..0e96fb9528 100644 --- a/deployments/2-bm/beamline.yaml +++ b/deployments/2-bm/beamline.yaml @@ -558,6 +558,13 @@ detector: firmware_version: "1710.0.0.0" part_number_reported: "Oryx ORX-10G-51S5M" # IOC-reported; catalog SKU ORX-10G-51S5M-C is the same class (10G vs 10GS = form factor only) replaceable: true + note: >- + This same physical camera (serial 19173710) also serves the 2-BM + vibration / flat-field-stability characterization: that is a high-frame- + rate operating mode (about 99 fps, 1000-frame HDF5 stream), not separate + hardware (VIB-1, #265). The February 2026 vibration study (item_070) was a + one-off, inconclusive investigation, so no standing vibration Procedure or + Caution is modeled (VIB-2..7, #267). - name: Camera_HighRes family: Camera # camera 1 (item_020): FLIR Oryx 31 MP, the alternate detector selected by Camera_Selector model: flir_oryx_31mp diff --git a/deployments/aps/site.yaml b/deployments/aps/site.yaml index 5fe6f138a4..a43f6f10ff 100644 --- a/deployments/aps/site.yaml +++ b/deployments/aps/site.yaml @@ -50,7 +50,6 @@ practices: - {name: Per-objective resolution variant, method: resolution_alignment, pending: true, note: "Mitutoyo 1.1x / 2x / 10x objectives"} - {name: 2BM_energy_characterization_practice, method: energy_characterization, pending: true} - {name: 2BM_ioc_restart_practice, method: ioc_restart, pending: true} - - {name: 2BM_vibration_baseline_practice, method: vibration_baseline, pending: true} - {name: 2BM_mirror_recoat_practice, method: mirror_recoat_return, pending: true} # Access BC Actors that are conceptually facility-wide at APS. Actor display diff --git a/docs/deployments/2-bm/questions.md b/docs/deployments/2-bm/questions.md index 570240be48..2db8b61c96 100644 --- a/docs/deployments/2-bm/questions.md +++ b/docs/deployments/2-bm/questions.md @@ -131,13 +131,6 @@ CORA will read proposal and user information from the APS scheduling system (the | SCHED-2 | `Nice-to-have` | Is the beamline staff contact (local contact) for a beamtime listed among that experiment's users in the scheduling system, or tracked separately as a beamline-side assignment? | listed as one of the beamtime's people | not yet | [2-BM index](index.md) | | SCHED-3 | `Nice-to-have` | Are APS badge numbers ever reused or reassigned to a different person over time, or is a badge number stable for life per person? And under APS data governance, is a badge number classified as personal data subject to deletion on request? Confirmer: APS User Office / data-management contact. | badge stable per person; classified as deletable personal data | not yet | [2-BM index](index.md) | -## Vibration and beam stability - -The [docs2bm item_070 page](https://docs2bm.readthedocs.io/en/latest/source/ops/item_070.html) documents three characterization measurements of the beamline itself: a high-speed vibration baseline, an air-handler shutdown test, and a multi-hour flat-field stability run. CORA models these as subject-less characterization captures, the Pending [`vibration_baseline`](procedures.md) Procedure / Run / Dataset and two operator [Cautions](cautions.md); the FFT and stripe-motion analysis stays downstream. These rows confirm the real-beamline facts that turn those stubs into records. Source: the staff-authored item_070 page. - -| ID | Priority | Question | CORA assumes | Already done? | Resolves | -| --- | --- | --- | --- | --- | --- | - ## Not on this page Hardware CORA has deliberately not described yet (the wider sample-stage motor band, IOC-hosted devices, past high-speed cameras) raises questions here only once CORA starts describing it. The `Mirror` is the exception that proves the rule: it is a registered Asset ([Inventory](inventory.md#inventory)) and its coating-stripe sweep is now modelled (`Mirror_StripeReachX`); only the coordinated mirror-table X binding stays open (`MODE-3`), blocked on the IOC substitution fix.