What CORA needs the LCLS team (and SLAC's documentation) to confirm before the model can be trusted.
MFX is modelled from SLAC's open pcdshub stack, treated as a dry, correct DATA source: the happi device database (device_config/db.json), the worked hutch config (mfx/beamline.py), the lightpath beam-walk engine, and pcdsdevices. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the calibrated numbers, the PPS safety structure, the undulator specifics, or the Capability / Method binding. This page collects what pcdshub cannot supply. It is a delete-on-answer queue: when an item is answered, the answer lands in the descriptor and the row is removed. Priorities are Blocks-build, Blocks-go-live, and Nice-to-have.
As at the Diamond exercises, the EPICS PV prefix for every device is already recorded in the descriptor, so wiring handles is not a question here. The questions concentrate on the one thing the storage-ring exercises never reached: the XFEL acquisition paradigm.
Is MFX (or any LCLS instrument) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source?
A generalization exercise: MFX tests the XFEL acquisition paradigm; it is not on the pilot roadmap.
Whether SLAC is a real Site or a modelling fixture.
TOPO-1
Blocks-build
One linac and undulator line feed many co-equal instruments (CXI/XPP/XCS/MEC/MFX, plus the LCLS-II soft-X-ray instruments), beam routed to one at a time. Should each instrument be its own root Unit sharing an upstream source, and where does the shared switched source live?
One LCLS-MFX root Unit owning its source for now; the shared, switched FEL source has no model and is carried as this question. The Supply("PhotonBeam") seam is the candidate home.
One-vs-many root Units and where the shared source and its routing state are modelled.
PSS-1
Blocks-build
What are the LCLS PPS search-and-secure permit signals, and the BTPS interlock for the pump-probe laser?
Both enclosures exist with permit signals to be named; pcdshub does not carry them.
The Enclosure permit signals and the laser-safety interlock.
ENC-1
Blocks-build
Which enclosure does each device sit in? pcdshub prefixes encode beamline-line zones (FEE, XRT, HFX, MFX:DG1/DG2/DIA), not the access-gated hutch or its safety meaning.
The shared front-end / transport zone plus the MFX experiment hutch.
What are the HXR undulator line parameters and the per-shot photon-energy mechanism (vernier vs undulator), and is the beam SASE or self-seeded? pcdshub carries the device handles, not the source curve.
A SASE FEL undulator; per-shot photon energy is a DAQ datum, not a standing setpoint; energy-to-gap control is deferred.
The Undulator parameters and the per-shot energy mechanism.
MACHINE-1
Nice-to-have
LCLS is a linac, not a storage ring, so the loose StorageRing family used by the synchrotron exercises does not fit. How should machine beam be modelled?
A PhotonBeam Supply, not a StorageRing device; the per-shot pulse energy is read via a FluxMonitor gas detector.
The linac machine-state modelling boundary.
ATT-1
Blocks-go-live
The solid-Si attenuators select a foil combination for a requested transmission (energy-dependent, the AttBase solver). CORA's Filter covers the discrete selection but not the solve. Should the deferred Attenuable + SolverReference leg graduate?
Filter for the discrete selection; the target-transmission solver is the deferred Attenuable leg, and MFX is its rule-of-three trigger.
Whether the transmission solver is built and where.
MONO-1
Nice-to-have
The diamond double-channel-cut mono (DCCM) is used for some modes; MFX also runs pink / SASE beam mono-out. What are the crystal and axis details, and the pink-vs-mono mode boundary?
A Monochromator Asset, used in some modes; mode and crystal details are settings to supply.
The DCCM internals and the pink-vs-mono mode model.
The LCLS DAQ records a free-running stream of per-shot frames tagged by pulse-ID / fiducial at beam rate (120 Hz to ~1 MHz), correlated downstream by pulse-ID. CORA's acquisition is a single-detector poll-to-Done loop plus a sub-Hz scalar observation logbook with no pulse-ID key. How does CORA represent a DAQ run?
The Run-as-provenance-envelope is kept; the per-shot data plane lives in psana, and CORA references a Dataset, exactly as it does for reconstructions via ComputePort. A per-shot event-stream actuation axis is the gap, sketched in the design note, not built.
Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for MFX.
TIMING-1
Blocks-go-live
The EventSequencer plays a beam-synchronous sequence (each line [beam_code, delta_beam, delta_fiducial, burst_count]) to gate acquisition. CORA's TimingController carries the device but has no typed home for an event-code sequence. Where does the sequence parameter live?
TimingController for the device; the event-code sequence is carried as opaque setpoints until a typed parameter shape is earned.
The event-code-sequence parameter model.
LASER-1
Blocks-go-live
The fs pump-probe needs laser-to-X-ray synchronization (the lxt_ttc SyncAxis, ~50 fs deadband) and timetool jitter correction. CORA's PartitionRule is single-domain spatial math, with no cross-timing-domain sync; and is the laser a driven Asset or a hazard?
The laser is carried as a loose Laser family device (the 4-ID precedent, model-vs-hazard open); the delay stage is a LinearStage; the fs synchronization has no CORA model.
The pump-probe synchronization model and the laser's model-vs-hazard status.
LIGHTPATH-1
Nice-to-have
lightpath computes path-level transmission and the first blocking device from each device's inserted / removed state along the z-walk. CORA has the static z-ordered walk and location-not-identity, but not the dynamic device-state-to-path-transmission computation (the passive-beam-path tier defers the beam effect). Should it graduate?
The static walk is modelled; the dynamic computed transmission is deferred under the passive-beam-path tier; lightpath/path.py is the precedent.
Whether the computed lightpath beam-effect is built.
How are the intensity-position monitors (IPM), the gas detector, the Wave8, and the timetool modelled? They present the Sensor Role; the gas detector is a BeamStats PV, not a happi device.
The loose FluxMonitor and Diagnostic Sensor families reused from I22 / 2-BM; per-shot intensity normalization is a DAQ-plane concern (DAQ-1).
The diagnostics modelling boundary.
SAMPLE-1
Blocks-go-live
What is the sample-delivery shape (liquid jet, fixed target), and the Subject custody lifecycle for serial crystallography?
Sample delivery is endstation-specific and deferred; no Family is coined yet; the Subject thread is carried as this question.
The sample-delivery model and the Subject custody thread.
SPEC-1
Nice-to-have
The von Hamos 6-crystal spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector along a dispersive geometry. The Family question is resolved: EmissionSpectrometer GRADUATED into the catalog once NSLS-II ISS (8-ID) earned the second sighting. The residual question is whether each of the six analyzer crystals is a child Asset or a setting on the one spectrometer Asset.
The six analyzer crystals carried as settings on the one EmissionSpectrometer Asset for now; child-Asset-per-crystal deferred.
The analyzer-crystal composition (child-Asset vs setting).
DET-1
Blocks-go-live
What is the MFX area detector (Rayonix MX340-XFEL, ePix10k, Jungfrau), and its threshold / geometry? pcdshub manages it through the DAQ, not as a polled happi device.
The detector reuses Camera; per-shot frames flow through the DAQ data plane (DAQ-1); the model and calibration are to supply.
The detector model and how its per-shot frames are referenced.
PULSE-1
Nice-to-have
The pulse picker is a fast single-pulse selector folded into Shutter. Is a rotary pulse-picking chopper a distinct Family (the loose Chopper shape)?
Shutter Role; the Shutter-vs-Chopper distinction is carried as this question.