Life of an experiment
Beam time — your scheduled hours with the neutron or muon beam pointed at your sample — is one of the scarcest resources in science: ~1,200 experiments a year, allocated by peer review, scheduled months ahead, and over in a few days. Here’s the whole journey — and where the software you build or run fits into it.
Proposal to paper
Click each phase to see what happens, who is involved, and which software is in the critical path.
01 — Propose
A research team writes a short scientific case: what they want to measure, on which instrument, and why it matters. There are three application routes: the main twice-a-year call (“Direct Access”, deadlines around mid-April and mid-October), plus fast-track “Rapid Access” and “Xpress” routes for urgent or simple measurements.
- who’s involved
- Visiting researchers, with advice from ISIS instrument scientists.
- systems & software
- Proposal submission system and user database.
The short version: proposal → panel review (~6 weeks) → beam time roughly 3–8 months after the deadline. During Measure, every detected event is timestamped and the sample conditions are logged alongside.
A day on an instrument
ISIS runs in cycles — stretches of several weeks with beam on around the clock, separated by maintenance shutdowns. During a cycle, an instrument is handed from one user team (ISIS-speak for the visiting researchers) to the next with barely a gap; experiments run through the night with support staff on call.
A typical allocation is two to five days. There are no do-overs: if equipment, beam, or software loses six hours, that might be a quarter of someone’s experiment — possibly one they waited eight months for. It’s the closest science gets to a live production deployment.
A run schedule is mostly “measure” — every other block is something the team tries to minimize.
Where the data goes
Want the reduction step hands-on? Drive the pipeline yourself →