16 Integration of Detectors into a Large Experiment: Examples from ATLAS. . .
739
The trigger and data acquisition (DAQ) system of an experiment at a hadron
collider plays an essential role because both the collision and the overall data rates
are much higher than the rate at which one can write data to mass storage. As
mentioned previously, at the LHC, with the beam crossing frequency of 40 MHz,
at the design luminosity of 10 34 cm −2 s −1 , each crossing results in an average of
∼23 inelastic p-p collisions with each event producing approximately 1–2 MB of
zero-suppressed data. These figures are many orders of magnitude larger than the
archival storage as well as the offline processing capability, which correspond to
data rates of 200–300 MB/s, or of 100–200 Hz.
The required event rejection power of the real-time system at design luminosity
is thus of O(10 7 ), which is too large to be achieved in a single processing step, if a
high efficiency is to be maintained for the physics phenomena of interest. For this
reason, the selection task is split into a first, very fast selection step, followed by
two steps in which the selection is refined.
The first step (L1 trigger) makes an initial selection based on information of
reduced granularity and resolution from only a subset of detectors. This L1 trigger
is designed to reduce the rate of events accepted for further processing to less than
100 kHz, i.e. it provides a rejection of a factor ∼10 4 with respect to the collision
rate. The figure of 100 kHz is an ‘asymptotic’ one, to be fully used at the highest
luminosities when the beam and experiment conditions demand it, and financial
resources allow it. It is expected that at startup, and also during the first years of
LHC operation, the L1 trigger will operate at lower rates.
The second step (high-level trigger or HLT) is designed to reduce the L1 accept
rate to the final output rate of ∼10 2 Hz. Filtering in the HLT is provided by software
algorithms running in large farms of commercial processors, connected to the
detector readout system via commercial networks. The physical implementation of
the HLT selection is implemented in a two-step process, with independent farms for
each of the two steps.
Some key requirements on the overall system are:
• To provide enough bandwidth and computing resources, within financial constraints, to minimise the dead-time at any luminosity, while maintaining the
maximum possible efficiency for the discovery signals. The current goal is to
have a total dead-time of less than a few (1–2)%. Most of this dead-time is
currently planned to occur in the L1 trigger.
• To be robust, i.e. provide an operational efficiency which does not depend
significantly on the noise and other conditions in the detector or on changes with
time of the calibration and detector alignment constants.
• To provide the possibility of validating and of computing the overall selection
efficiencies using only the data themselves, with as little reference to simulation
as possible. This implies usage of multiple trigger requirements with overlapping
thresholds.
• To uniquely identify the bunch crossing that gave rise to the trigger.
• To allow for the readout, processing and storage of events that will be needed for
calibration purposes.
739
The trigger and data acquisition (DAQ) system of an experiment at a hadron
collider plays an essential role because both the collision and the overall data rates
are much higher than the rate at which one can write data to mass storage. As
mentioned previously, at the LHC, with the beam crossing frequency of 40 MHz,
at the design luminosity of 10 34 cm −2 s −1 , each crossing results in an average of
∼23 inelastic p-p collisions with each event producing approximately 1–2 MB of
zero-suppressed data. These figures are many orders of magnitude larger than the
archival storage as well as the offline processing capability, which correspond to
data rates of 200–300 MB/s, or of 100–200 Hz.
The required event rejection power of the real-time system at design luminosity
is thus of O(10 7 ), which is too large to be achieved in a single processing step, if a
high efficiency is to be maintained for the physics phenomena of interest. For this
reason, the selection task is split into a first, very fast selection step, followed by
two steps in which the selection is refined.
The first step (L1 trigger) makes an initial selection based on information of
reduced granularity and resolution from only a subset of detectors. This L1 trigger
is designed to reduce the rate of events accepted for further processing to less than
100 kHz, i.e. it provides a rejection of a factor ∼10 4 with respect to the collision
rate. The figure of 100 kHz is an ‘asymptotic’ one, to be fully used at the highest
luminosities when the beam and experiment conditions demand it, and financial
resources allow it. It is expected that at startup, and also during the first years of
LHC operation, the L1 trigger will operate at lower rates.
The second step (high-level trigger or HLT) is designed to reduce the L1 accept
rate to the final output rate of ∼10 2 Hz. Filtering in the HLT is provided by software
algorithms running in large farms of commercial processors, connected to the
detector readout system via commercial networks. The physical implementation of
the HLT selection is implemented in a two-step process, with independent farms for
each of the two steps.
Some key requirements on the overall system are:
• To provide enough bandwidth and computing resources, within financial constraints, to minimise the dead-time at any luminosity, while maintaining the
maximum possible efficiency for the discovery signals. The current goal is to
have a total dead-time of less than a few (1–2)%. Most of this dead-time is
currently planned to occur in the L1 trigger.
• To be robust, i.e. provide an operational efficiency which does not depend
significantly on the noise and other conditions in the detector or on changes with
time of the calibration and detector alignment constants.
• To provide the possibility of validating and of computing the overall selection
efficiencies using only the data themselves, with as little reference to simulation
as possible. This implies usage of multiple trigger requirements with overlapping
thresholds.
• To uniquely identify the bunch crossing that gave rise to the trigger.
• To allow for the readout, processing and storage of events that will be needed for
calibration purposes.