Notes on RFox's Tcl2008 talk.
Ron started by showing a URL for a LHC webcam.
http://www.cyriak.co.uk/lhc/lhc-webcams.html
Collisions cannot be controlled. The experiment is usually only interested in particular types of collisions. The beam is never "pure." The beam is never mono-energetic. "Impact parameter" is random (like throwing ping pong balls against a bead curtain). God does play dice with the universe.
Experimentalists use coincidence requirements and require bunch of conditions to analyze only the "interesting collisions."
Work done for Finland's Radiation and Nuclear Safety Authority. http://www.stuk.fi
Environmental Nuclear Physics
- What are nuclear power plants emitting?
- Is there Radon in your basement?
- Is that lab that's not making weapons really not making weapons?
- Where did the former Soviet Union dump all those spent submarine reactor cores anyway?
(... various images shown and explained ...)
Methods: Gamma ray spectroscopy
- Background is huge
- Naturally occurring isotopes give you false positives
- Naturally occurring isotopes can confuse peak identification
Borrowing from accelerator experiments:
- most interesting nuclear decays are fissionable isotopes
- Fissionable isotopes emit: gamma-rays at a characteristic energy, alpha particles
- ...
STUK PANDA program
- PANDA: Particles And Non Destructive Analysis
- Study feasibility of using alpha-gamma coincidence techniques to remove background
- Identify particles in place in filter
- ...
Why a Domain-Specific Language, Tcl?
- Hardware is tough to program
- Consistency between readout configuration and event unpacking
- Quicker to change a DSL description than to program
- Using Tcl as a base language for a DSL provides a fully programmable description language
DSL scope:
- Hardware definition and configuration
- Trigger definitions
- Modules and order in which modules are read for each trigger definition
- Unpacking the events from each trigger definition
- Automatic creation of raw parameter spectra
- Application specific spectra
DSL concepts:
- There are devices
- Devices have configuration options that fake typed values that must be validated
- Each device type has an associated software component with a well defined interface: construction; initialization; contribute instructions to trigger list
- The order in which devices are read determines the structure of an event
deviceType create name ?options?
deviceType config name option value ...
deviceType cget name
(... showed sample configuration file ...)
Configuration options:
- Option values are typed
- Each driver instance has a configuration
- Driver declares set of options, value validators
- Stock validators exist for common types
(... showed some spectra results ...)
What worked well:
- Flexibility: DSSD Strip mapping changed several times during visit. Config file was changed faster than the re-cabling could be done.
- Training: 1 hour of training (including teaching of the endekalogue) and users were making their own config file changes
- Stability: Results of the Thule particle test run were reproduced easily during my vacation
- System power: the system was able to make a much cleaner determination of the Pu peak for the Thule particle
What I'd change:
- Smaller C/C++ primitives (readout); a device driver could then be in Tcl. New hardware support by end users might then be possible.
- Validators in Tcl.
Conclusions:
- A system using a domain specific language to describe nuclear physics experiments was deployed at STUK
- The flexibility of a DSL made analysis of hardware defects relatively simple
- With a very short training time ...
- ...