Skip to content

Open questions

What CORA needs the PSI team (and PSI's documentation) to confirm before the model can be trusted.

Alvra is modelled from PSI's open eco controls library, treated as a dry, correct DATA source: the Alvra manifest is the aliases dict in eco/alvra/config.py, and the per-device driver classes derive the motor axes from each PV prefix. That gives the device shape and the EPICS PV prefixes at high confidence; it does not give the motor units or limits, the Aramis source parameters, the PSS safety structure, or the Capability / Method binding, none of which is in the manifest. This page collects what eco 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 LCLS-MFX and 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 XFEL acquisition paradigm and on the few eco-specific ambiguities the source itself leaves open.

Scope, topology, and safety

ID Priority Question CORA assumes Resolves
SCOPE-1 Nice-to-have Is Alvra (or any SwissFEL station) actually intended to enter CORA scope, or is this a generalization exercise against an open controls source? A generalization exercise: Alvra is CORA's second XFEL, testing whether the XFEL findings generalize across facilities; it is not on the pilot roadmap. Whether PSI is a real Site or a modelling fixture.
TOPO-1 Blocks-build One linac and Aramis undulator line feed the Alvra, Bernina, and Cristallina stations, beam routed to one at a time. Should each station be its own root Unit sharing an upstream source, and where does the shared switched source live? One Alvra 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 SwissFEL PSS search-and-secure permit signals, and the interlock for the pump-probe laser? Both enclosures exist with permit signals to be named; eco does not carry them. The Enclosure permit signals and the laser-safety interlock.
ENC-1 Blocks-build Which enclosure does each device sit in? eco prefixes encode beamline-line zones (SARFE10, SAROP11, SARES11 / SLAAR11), not the access-gated hutch or its safety meaning. The shared Aramis optics hutch plus the Alvra experiment hutch. The per-device Enclosure assignment.

Source, optics, and attenuation

ID Priority Question CORA assumes Resolves
SRC-1 Blocks-build What are the Aramis undulator line parameters and the per-shot photon-energy mechanism? The eco manifest carries the downstream device handles, not the source. 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 SwissFEL 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 the FluxMonitor gas / intensity monitors. The linac machine-state modelling boundary.
ATT-1 Blocks-go-live The AttenuatorAramis driver selects a foil combination for a requested transmission (energy-dependent). 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. With LCLS-MFX carrying the same solve, the rule-of-three is well past its trigger. Whether the transmission solver is built and where.
MONO-1 Nice-to-have The double-crystal mono (ODCM105) is used for monochromatic / spectroscopy modes; Alvra 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 DCM internals and the pink-vs-mono mode model.
XREF-1 Blocks-go-live Several Alvra eco drivers reference SAROP21-* PVs (a sibling Aramis line): the reference laser hardcodes an aperture on SAROP21-OLIR134, and the joint mono+FEL energy device reads SAROP21-ODCM098:ENERGY. Is this correct for Alvra, or a copy-paste artifact in the library? The Alvra-line PVs (SAROP11-*) are authoritative; the SAROP21-* references are carried confirm, not silently modelled. Whether the cross-line references are real Alvra dependencies.

Acquisition and timing (the architectural core)

ID Priority Question CORA assumes Resolves
DAQ-1 Blocks-build The SwissFEL sf-daq records a free-running bsread stream of per-shot frames tagged by pulse-ID at beam rate, correlated downstream. 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 the SwissFEL data API, 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. This is the same gap LCLS-MFX exposed; Alvra is the second sighting. Whether CORA gains an event-stream acquisition axis or remains a record-keeping shell for Alvra.
TIMING-1 Blocks-go-live The SwissFEL event system (EVR receivers, e.g. SLAAR11-LTIM01-EVR0) gates acquisition at beam rate. CORA's TimingController carries the device but has no typed home for an event trigger pattern. Where does the pattern parameter live? TimingController for the device; the trigger pattern is carried as opaque setpoints until a typed parameter shape is earned. The event-system trigger-pattern parameter model.
LASER-1 Blocks-go-live The fs pump-probe needs laser-to-X-ray synchronization (the eco lxt timing chain) and PALM / PSEN 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 catalog Laser Family device (the LCLS-MFX / 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.

Diagnostics, sample, and detector

ID Priority Question CORA assumes Resolves
DIAG-1 Blocks-go-live How are the intensity-position monitors (PBPS), the gas monitor (PBIG), and the PALM / PSEN arrival-time monitors modelled? They present the Sensor Role. The loose FluxMonitor and Diagnostic Sensor families reused from I22 / 2-BM / LCLS-MFX; 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 on the Prime endstation (fixed target, liquid jet), 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 spectrometer is a crystal-analyzer X-ray emission spectrometer composing analyzer crystals and a 2D detector. The Family question is resolved: EmissionSpectrometer is in the catalog (Alvra is a fourth sighting). The residual question is whether each analyzer crystal is a child Asset or a setting on the one spectrometer Asset. The 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 Alvra science detector? eco binds a Jungfrau named JF_4.5M (the von Hamos 4.5M, serial JF02T09V03 inferred via sf_daq_broker), and the broker lists further Alvra options (16M, 4M, 2M TXS, 0.5M variants). Which is in use, and its threshold / geometry? The detector reuses Camera; per-shot frames flow through the sf-daq data plane (DAQ-1); the model, the active variant, and the calibration are to supply. The detector model and how its per-shot frames are referenced.
PULSE-1 Nice-to-have The X-ray 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, the same one LCLS-MFX raised. Whether the pulse picker earns its own Family.