16 Integration of Detectors into a Large Experiment: Examples from ATLAS. . .
763
16.8.4 Trigger Performance
The trigger involves, by design, the selection of only a small fraction of the p−p
collisions at the LHC. As a result, a number of compromises on the extent of
the physics programme have had to be made. This is an important difference with
respect to the experience in e + e − machines.
Efficient use of DAQ bandwidth requires that two conditions be fulfilled. First,
each level of the trigger attempts to identify physics objects (leptons, photons
and jets) as efficiently as possible, while keeping the output bandwidth within
requirements. The selected event sample should include all events which would
be found by the full offline reconstruction. Hence, the cuts in the trigger must
be consistent with those of the offline analysis. Second, since the bandwidth to
permanent storage media is limited, events must be selected with care at the final
trigger level.
A crucial ingredient of physics analysis is the determination of the trigger
efficiency. Three tools allowing the measurement of the requirements imposed by
the L1 trigger have been included in the designs. One tool is the presence of
overlapping programmable triggers, which allows triggers with different thresholds
and cuts to run simultaneously, producing multiple results in parallel. A second tool
is prescaled triggers with either lower thresholds or looser requirements (or both)
to run in parallel with the main algorithm. A third tool is prescaling of a particular
trigger with one of its cuts removed.
Beyond these three tools, another method for measuring the trigger efficiency,
which is used extensively, is the use of processes with two physics objects where
the trigger selects one of the two. As an example, Z → ee decays, selected via
the single-electron trigger, can be used to measure the electron trigger efficiency by
examining the second, unbiased, electron leg.
A key task is the creation of the trigger tables, i.e. the requirements demanded
online, by both the L1 and HLT systems, on the events selected. Table 16.14 lists
two examples from ATLAS and CMS, for the L1 trigger. There are, naturally, very
significant uncertainties in these rate estimates. At one extreme, CMS allocates
only one-third of the assumed DAQ bandwidth to specific triggers. In the ATLAS
case, the plan is to absorb any differences in rate via changes in thresholds. Both
experiments plan to allocate bandwidth to B physics as well, within the limitations
of the total resources available, at the initially low luminosities of the LHC.
The real-time nature of the selections imposes very stringent requirements on
the monitoring of the L1 and HLT performance. Initially, many triggers will be run
in forced-accept mode, thereby providing the possibility to analyze in detail their
performance offline. The trigger monitoring itself will employ a number of tools,
including the storage of a small fraction of the events rejected, the comparison of
the actual online decisions (as obtained from intermediate hardware calculations
that will be stored along with the detector data) and a number of unbiased events,
or “minimum-bias” events, which are selected at random, i.e. without any specific
requirements on the bunch crossing in question.
763
16.8.4 Trigger Performance
The trigger involves, by design, the selection of only a small fraction of the p−p
collisions at the LHC. As a result, a number of compromises on the extent of
the physics programme have had to be made. This is an important difference with
respect to the experience in e + e − machines.
Efficient use of DAQ bandwidth requires that two conditions be fulfilled. First,
each level of the trigger attempts to identify physics objects (leptons, photons
and jets) as efficiently as possible, while keeping the output bandwidth within
requirements. The selected event sample should include all events which would
be found by the full offline reconstruction. Hence, the cuts in the trigger must
be consistent with those of the offline analysis. Second, since the bandwidth to
permanent storage media is limited, events must be selected with care at the final
trigger level.
A crucial ingredient of physics analysis is the determination of the trigger
efficiency. Three tools allowing the measurement of the requirements imposed by
the L1 trigger have been included in the designs. One tool is the presence of
overlapping programmable triggers, which allows triggers with different thresholds
and cuts to run simultaneously, producing multiple results in parallel. A second tool
is prescaled triggers with either lower thresholds or looser requirements (or both)
to run in parallel with the main algorithm. A third tool is prescaling of a particular
trigger with one of its cuts removed.
Beyond these three tools, another method for measuring the trigger efficiency,
which is used extensively, is the use of processes with two physics objects where
the trigger selects one of the two. As an example, Z → ee decays, selected via
the single-electron trigger, can be used to measure the electron trigger efficiency by
examining the second, unbiased, electron leg.
A key task is the creation of the trigger tables, i.e. the requirements demanded
online, by both the L1 and HLT systems, on the events selected. Table 16.14 lists
two examples from ATLAS and CMS, for the L1 trigger. There are, naturally, very
significant uncertainties in these rate estimates. At one extreme, CMS allocates
only one-third of the assumed DAQ bandwidth to specific triggers. In the ATLAS
case, the plan is to absorb any differences in rate via changes in thresholds. Both
experiments plan to allocate bandwidth to B physics as well, within the limitations
of the total resources available, at the initially low luminosities of the LHC.
The real-time nature of the selections imposes very stringent requirements on
the monitoring of the L1 and HLT performance. Initially, many triggers will be run
in forced-accept mode, thereby providing the possibility to analyze in detail their
performance offline. The trigger monitoring itself will employ a number of tools,
including the storage of a small fraction of the events rejected, the comparison of
the actual online decisions (as obtained from intermediate hardware calculations
that will be stored along with the detector data) and a number of unbiased events,
or “minimum-bias” events, which are selected at random, i.e. without any specific
requirements on the bunch crossing in question.