What CORA needs the i10 team to confirm before the model can be trusted.
i10 was reverse-engineered from the beamline's own bluesky device layer (DiamondLightSource/dodal: the src/dodal/beamlines/i10*.py factories and the src/dodal/devices/ classes), so the control handles on the device pages are the beamline's real PVs, read from dodal rather than confirmed by staff. Each row below is a fact the beamline team owns, not a CORA modelling choice (those are on Model). It is a delete-on-answer queue. Priorities are Blocks-build, Blocks-go-live, and Nice-to-have.
Both APPLE-IIs are driven sources (energy_dd over IDD, energy_ud over IDU); should CORA carry one incident-energy axis or two, and how do they map to the branches?
One BeamEnergyPseudoAxis over the PGM and the APPLE-II gap; the two-source wiring pending.
The incident-energy Asset wiring.
POL-1
Blocks-go-live
The polarization value domain (LH / LV / PC / NC / LA plus third-harmonic variants and the continuous linear-arbitrary-angle) and the polarization-to-phase conversion: pin it as a CORA Calibration, or run the axis rule-less and let the live controller own it?
A PseudoAxis over the APPLE-II phase rows; the linear-arbitrary-angle is the continuous realization of LA in the same axis; rule-less by default.
The RASOR diffractometer circle roles (two-theta scattering arm, sample theta / chi, chamber X, alpha) and whether they compose an Assembly.
A Goniometer for the sample circles; the Assembly(Diffractometer) is named, not built.
The diffractometer geometry; the CORA structural modelling is on Model.
DIFF-2
Nice-to-have
The reciprocal-space coordination over the RASOR circles (the inverse-kinematics rule).
A reciprocal-space PseudoAxis over the circles, the rule deferred as on 4-ID / 8-ID / i06-1.
The reciprocal-space Asset.
POL-2
Blocks-go-live
Does RASOR run genuine polarization analysis on the PaStage (the POLAN arm), confirming the analyzer-crystal spec on the catalog PolarizationAnalyzer Family?
The PaStage binds the catalog PolarizationAnalyzer (graduated across 4-ID / i10 / ID32 / P09); dodal exposes the motors only, the analyzer crystal is implicit, so the crystal spec stays a per-Asset detail to confirm.
The analyzer-crystal spec; the graduation is recorded on Model.
STAGE-1
Nice-to-have
Whether the cryostat sample stage warrants a Manipulator rather than LinearStage, and whether the pinhole is an Aperture or a plain stage.
The sample stage bound to LinearStage (plain in-air translation); the pinhole bound to Aperture.
The sample-stage and pinhole Families.
TEMP-1
Nice-to-have
The Lakeshore 340 (RASOR) and Lakeshore 336 (i10-1) temperature ranges and channel assignment.
Two TemperatureController Assets presenting the Regulator Role; ranges pending.
The temperature-control modelling.
DET-1
Blocks-go-live
The RASOR and i10-1 detection: no area detector exists in dodal, only the current-amplifier / scaler point-counting chains (monitor, scattered-beam point detector, fluorescence, drain-current / total-electron-yield). Is the point detector best a FluxMonitor, or does scattered-beam point-counting earn its own Sensor Family?
The scattered-beam point detector and the monitor / fluorescence / yield channels bind FluxMonitor; no detector Family invented.
The i10-1 electromagnet and superconducting field-sweep magnet (field ranges, the sweep mode), and the low-temperature environment.
The two magnets bind the graduated catalog Magnet Family (one Family, the sweep is a per-Asset affordance); i10-1 was one of its three consumers with 4-ID and ID32; the cryostat folds into the stage.
The per-Asset magnet field / control detail; the family graduation is settled (see Model).
Do the resonant-scattering, reflectivity, and magnetic-dichroism techniques (RSXS, soft X-ray reflectivity, XMCD, XMLD) enter CORA's catalog as Capabilities / Methods?
Deferred: carried as pending Practices; resonant scattering and XMCD share the 4-ID Methods, XMLD shares the i06 slug, reflectivity is a new pending slug; none coined.
Every row above is a question about the real beamline, and any of them can be
answered by someone who knows the hardware. You do not need to edit this page
or know where it lives.
Open a short issue at
github.com/xmap/cora/issues, quote the
item ID, and write the answer in plain text. One answer is as welcome as
several. If you do not use GitHub, send the same thing to whoever shared this
page with you. If a row turns out to be a controls, network, or engineering
question, pass it to the right person or tell us who that is.
The priorities mean: Blocks-build, your answer changes the structure of the
description, so CORA cannot finalise it until you reply; Blocks-go-live, a
guess is fine for the description, but the real value is needed before CORA
controls or observes the hardware; Nice-to-have, extra detail for the record.
Once an item is confirmed we record the value and delete the row, so this page
always shows only what is still open.