Speaker
Description
In its high luminosity phase, the Large Hadron Collider (LHC) will
achieve unprecedented levels of instantaneous luminosity
of up to $7.5\times10^34 $cm$^2$s$^{-1}$, which exposes the ITk (Inner Tracker) Pixel
detector of the ATLAS experiment to extraordinary levels of radiation.
A maximum fluence of $9.2\times10^15$cm$^{-2} 1$MeV $n_{eq}$ in the harshest radiation
region at the innermost detector layers is expected.
To keep occupancy low in these conditions, the number of pixels will
increase from ~92 million in the current ATLAS Pixel Detector to ~5 billion.
Each pixel holds configuration data which has to be constantly
reprogrammed and monitored while the detector is taking data.
The configuration of all these pixels has to be kept available rapidly
at all times throughout operation.
Due to levels of radiation exposure never seen before, easy and quick
evolution monitoring must be possible in order to understand and
potentially mitigate radiation damage to the detector system.
Based on this monitoring, a re-calibration of the detector can be
derived, generating a new set of configuration data which has to be
applied to the pixels eventually.
Possibly updates of the configuration between accelerator fills will be
necessary.
To meet these challenging requirements, a distributed event sourced
configuration database has been proposed and is currently under development.
An event sourced database stores data as small updates, so-called domain
events, which restore the state of the system when played back into
so-called aggregates.
In our case, the aggregates are configuration object blueprints.
Once restored, the configuration objects are passed down to the data
acquisiton (DAQ) software.
By storing only differential updates of the configuration data it is
expected to achieve great savings in required storage, and great
increases in speed, compared to a solution that stores the full
configuration data for each version.
The database adheres to the CQRS principle in order to decouple writes
and reads.
This allows a fan-out topology of the database on the read-side, where
O(100) DAQ hosts should keep a subset of the total configuration data
destined to the respectively connected frontend detector hardware.
The optimal architecture to distribute the configuration data from the
central servers to the DAQ hosts is currently under study.
For example, to achieve strict consistency of configuration updates an
event bus fully integrated with the database is under investigation to
provide feedback about the state of the system.
Full-scale modelling of the database is underway on a SLURM cluster in
Wuppertal.
The implementation of the database in Python is expected to provide
ready access to the vast Python ecosystem for data analysis.