<table><caption>Table 3.7: Maximum Level-1 processing rate of the FTK system and reconstruction efficiency for tracks with $p_T$ above 1 GeV during the Phase-I and HL-LHC data-taking conditions. To recover 100 kHz processing rate during the HL-LHC the reconstruction efficiency required for tracks needs to be loosened to 60%.</caption><thead><tr><th>Parameter</th><th>μ = 80</th><th>μ = 200</th></tr></thead><tbody><tr><td>Max. Processing Rate [kHz]</td><td>100</td><td>5</td><td>100</td></tr><tr><td>Efficiency (for tracks with p<sub>T</sub> > 1 GeV)</td><td>~90%</td><td>~90%</td><td>~60%</td></tr></tbody></table>

the tail in the distribution suppressed, by relaxing the requirements on the reconstruction efficiency for tracks with $p_T$ above 1 GeV.

Table 3.7 summarises the FTK performance in the configuration optimised for Phase-I data taking and a crude estimation when the same configuration is used in a HL-LHC-like environment at 100 kHz Level-1 trigger rate. To maintain an efficiency of ~90% on tracks with $p_T$ above 1 GeV, the FTK would need to operate on only 5% of the events (equivalent to 5 kHz trigger rate in this case). Alternatively, the reconstruction efficiency would need to be relaxed to 60% to be able to run FTK on all the 100 kHz Level-1 triggered events. In order to get a reasonable efficiency, the track $p_T$ requirement would need to be raised to ~10 GeV.

This limitation in the FTK performance impacts the trigger selection of hadronically decaying $\tau$ leptons, b-tagged jets, single-jet events, multi-jet events, and $E_T^{miss}$, as described below.

### 3.4.3 Features and Limitations of Event Selection in the Run 3 HLT

The Run 3 HLT menu is designed for a peak output rate of 1.5 kHz (an average rate of 1 kHz) with ~2/3 of that allocated for leptonic triggers and ~1/3 for hadronic triggers. For single-lepton triggers, the production of W and Z bosons provides an important constraint on the HLT trigger menu. The goal of the Run 3 physics programme is not necessarily to collect as many single W and Z bosons as possible, but rather to use them to trigger physics processes such as associated Higgs production (WH and ZH) with minimal bias. This is achieved by postponing additional trigger selections except for those on the single lepton until the full detector information is available at the HLT. At the luminosities expected in Run 3, the total rate of electrons and muons from W boson decays is approximately 1.2 kHz, which by itself would saturate the allowed HLT output rate. The rate of full reconstruction for electron and muon events is expected to be 2.5 kHz. About 50% of these electrons and muons are inside the trigger acceptance, but even electron and muon selections with very tight isolation requirements at the HLT have considerable background from heavy quark decays and fake jets, raising the rate by a counterbalancing factor of two. Thus additional
rejection can be achieved by including additional event information (such as the presence of jets reconstructed in the HLT).

In the Run 3 HLT, the hadronic $\tau$ reconstruction strategy has two components. The first component is a simple selection based on the numbers of FTK tracks in a core and an isolation cone, defined with respect to the highest-$p_T$ track in the tau RoI (as described in Ref. [3.9]) to do a fast rejection. The second component is a more sophisticated algorithm involving topological clusters and tracks, mimicking the offline multivariate selection. Additionally, FTK tracks can be used to do full-scan tau finding to recover inefficiencies due to the relatively high tau $p_T$ threshold at Level-1. Final states involving hadronically decaying $\tau$ leptons predominantly have at least two trigger objects in the final state, allowing for very large rejection factors, as can be seen in Table 3.6. Therefore, it will generally be unnecessary to add objects beyond those used to seed the triggers at Level-1 in order to obtain low HLT output rates. Similarly, multi-object tau triggers with electrons and muons will have high rejection rates and will not require the identification of additional objects in the HLT.

The identification of jets arising from b-hadrons is a powerful tool for background rejection that is only available in the HLT. Historically, b-tagging algorithms were a large consumer of HLT CPU time. To maintain the same relative CPU usage as the rate of pile-up increases, the $p_T$ threshold of b-tagged jets must be raised to compensate for the increase in the number of jets present in the events and the more complicated pattern recognition task. By removing the pattern recognition and track-fitting step, the FTK allows the HLT to process many more RoIs for b-tagging. FTK tracks can be used directly by the tagger, or they can first be refit with the HLT fitting algorithms to improve the track parameter resolutions. In Ref. [3.9] it was shown that simple, pile-up-robust FTK b-tagging algorithms could be developed with only modest decreases in efficiency with respect to offline taggers.

For generic single-jet triggers and multi-jet triggers, full calorimeter readout allows more accurate determination of jet energies using the full offline jet calibration procedure, including pile-up suppression and correction. This allows the HLT thresholds to be placed very close to the offline ones. The full readout also allows iterative event-level jet-finding algorithms, such as the anti-$k_T$ algorithm, to be used. This requires that the HLT supports the full calorimeter readout rate in excess of 20 kHz, and that sufficient CPU resources are available for the topological clustering of the calorimeter information, as well as calibration close to what is used offline.

The most important of the hadronic triggers in the initial running at the LHC has been the $E_T^{miss}$ trigger, which has figured prominently in the Higgs analyses (e.g. $ZH \to \nu\bar{\nu}b\bar{b}$ as discussed in Section 2.6), as well as in the majority of the SUSY and Exotics analyses with hadronic final states. In Run 2 and Run 3, the expected increase in pile-up will inevitably degrade $E_T^{miss}$ performance and also lead to a large increase in soft jets from pile-up. Sophisticated pile-up-suppression techniques will be used at the HLT, and FTK tracks can be used to improve the calibration of the reconstructed jets in the trigger. For generic
$E_T^{\text{miss}}$ triggers, and for combined jet and $E_T^{\text{miss}}$ triggers, the HLT must closely match to the offline algorithm to maximise the overlap of events selected by the two algorithms. The $E_T^{\text{miss}}$ threshold for a generic $E_T^{\text{miss}}$ algorithm will have to be approximately a factor of 2 or 2.5 higher than the Level-1 threshold to obtain a factor of 100 rejection. It is anticipated that there will be a large number of specialised HLT algorithms seeded from Level-1 $E_T^{\text{miss}}$, which are based on jets (with and without b-tagging applied) that can have $E_T^{\text{miss}}$ thresholds closer to the Level-1 thresholds. For example, offline $E_T^{\text{miss}}$-based algorithms typically apply requirements on the direction of the $E_T^{\text{miss}}$ relative to hard jets in the event which can be implemented at the HLT.

## References

[3.1] ATLAS Collaboration, Technical Design Report for the Phase-II Upgrade of the ATLAS LAr Calorimeter, Tech. Rep. CERN-LHCC-2017-018. ATLAS-TDR-027, CERN, Geneva, Sep, 2017. https://cds.cern.ch/record/2285582.

[3.2] ATLAS Collaboration, Technical Design Report for the Phase-II Upgrade of the ATLAS Tile Calorimeter, Tech. Rep. CERN-LHCC-2017-019; ATLAS-TDR-028, CERN, Geneva, Sep, 2017. http://cds.cern.ch/record/2285583.

[3.3] ATLAS Collaboration, Technical Design Report for the Phase-II Upgrade of the ATLAS Muon Spectrometer, Tech. Rep. CERN-LHCC-2017-017. ATLAS-TDR-026, CERN, Geneva, Sep, 2017. https://cds.cern.ch/record/2285580.

[3.4] ATLAS Collaboration, Technical Design Report for the ATLAS Inner Tracker Pixel Detector, Tech. Rep. CERN-LHCC-2017-021, CERN, Geneva, (in preparation).

[3.5] ATLAS Collaboration, Technical Design Report for the ATLAS Inner Tracker Strip Detector, Tech. Rep. CERN-LHCC-2017-005, CERN, Geneva, Apr, 2017. https://cds.cern.ch/record/2257755.

[3.6] ATLAS Collaboration, Technical Design Report for the Phase-I Upgrade of the ATLAS TDAQ System, Tech. Rep. CERN-LHCC-2013-018. ATLAS-TDR-023, CERN, Geneva, Sep, 2013. https://cds.cern.ch/record/1602235.

[3.7] ATLAS Liquid Argon Calorimeter Group, ATLAS Liquid Argon Calorimeter Technical Design Report: Trigger Electronics for the LHC Phase-I Upgrade, Tech. Rep. CERN-LHCC-2013-017, CERN, Geneva, (in preparation). https://twiki.cern.ch/twiki/bin/view/LAr/LArPhaseITDR.

[3.8] ATLAS Collaboration, ATLAS New Small Wheel Technical Design Report, Tech. Rep. CERN-LHCC-2013-006. ATLAS-TDR-020, CERN, Geneva, Jun, 2013. https://cds.cern.ch/record/1552862.
[3.9] ATLAS Collaboration, *Fast TracKer (FTK) Technical Design Report*, Tech. Rep. CERN-LHCC-2013-007. ATLAS-TDR-021, CERN, Geneva, Jun, 2013. https://cds.cern.ch/record/1552953.

[3.10] ATLAS Collaboration, G. Aad et al., *Topological cell clustering in the ATLAS calorimeters and its performance in LHC Run 1*, Eur. Phys. J. C77 (2017) 490, arXiv:1603.02934 [hep-ex].

[3.11] S. Belforte et al., *The CDF trigger silicon vertex tracker (SVT)*, IEEE Trans. Nucl. Sci. (1995) 860.

[3.12] J. Adelman et al., *The Silicon Vertex Trigger upgrade at CDF*, NIM (2007) 361.
<figure><img src="image_54.png" /></figure>
# 4 Architectural and Functional Requirements

The upgraded TDAQ system shall allow for the broad physics programme planned for the HL-LHC, as described in Chapter 2, while maintaining the flexibility needed for standard triggers, exotic object triggers and the potential to respond to changing priorities. As described in [4.1], the Phase-II upgrade programme for the ATLAS detector contains a variety of improvements, such as extended coverage in the forward region for electrons, muons and charged particle tracks. ATLAS has come up with a consistent set of parameters for the design and implementation of the Phase-II upgrade for the subdetector systems and TDAQ. These are documented in an internal FE Interface Requirement Document [4.2], which defines also a formal approval process and revision control to ensure coherency.

This chapter is organised as follows. The detector improvements foreseen in Phase-II that impose constraints on the Phase-II TDAQ system are described in Section 4.1. Section 4.2 includes a summary of the Level-0 trigger requirements. The requirements driving the technical design of the Data Acquisition are described in Section 4.3. And finally, Section 4.4 describes the requirements on the EF system.

## 4.1 Constraints from the Detectors

### 4.1.1 New Inner Tracker

The new ATLAS Inner Tracker (ITk) proposed for the Phase-II upgrade is described in detail in two technical design reports: the ITk strip detector TDR [4.3] and the ITk pixel detector TDR [4.4]. Various characteristics provide constraints to the design of the TDAQ system in Phase-II and are described in the following.

#### Additional Coverage

The proposed ITk acceptance (up to $|\eta| < 4.0$) provides an opportunity to extend various triggers to include the forward region through regional or full-detector tracking. A calorimeter-only forward electron trigger is expected to have a high trigger rate due to the coarser calorimeter segmentation and high pile-up in the forward region. Such a trigger would therefore need to apply a high $p_T$ threshold or require a matching track. Identification of tau leptons and jets arising from b-hadrons may also be improved over the full
acceptance of the ITk, as well as track-based pile-up suppression to aid the performance of hadronic triggers.

### ITk Strip Detector

A primary driver of the TDAQ system architecture is the limitation on the readout rate of the ITk strip detector. The strip detector's on-detector ASICs, the core components of the FE electronics, are being designed to meet the preliminary trigger requirements for either the baseline or evolved TDAQ system options, including high priority requests for data in small regions of the detector needed for the evolved option. As detailed in [4.3], the on-detector data transmission is based on the Hybrid Controller Chip ASIC that transmits the data from 10 FE ASICs on a 640 Mbit e-link to end-of-stave cards housing one or two Low Power Gigabit Bidirectional Trigger and Data Link (lpGBT) transceivers. Table 4.1 shows for each barrel layer and endcap disc of the ITk strip detector the expected occupancy at $\langle \mu \rangle \simeq 200$, the hit rate, the effective payload in the lpGBT readout link for a 1 MHz readout rate when a 8b/10b encoding protocol is used, and the equivalent maximum trigger rate capability. The trigger rate capability is estimated considering that the available e-link bandwidth saturates within a 75% margin and that the time required to read out 99% of the data is less than 50% of the Level-0 latency (to minimise queuing effects in the Front-End ASICs). A constraint of a maximum of 1 MHz full-detector readout rate capability results from the ITk strip detector design.

<table><caption>Table 4.1: Expected maximum occupancy and payload per link for the various layers of the ITk-strip detector (from Ref. [4.3]). The last column is the maximum average trigger rate sustainable by the readout within a 75% margin on the available bandwidth of the readout link.</caption><thead><tr><th>Layer</th><th>Channel<br>Occupancy [%]</th><th>Hit Rate<br>/[mm<sup>2</sup>/BC]</th><th>Payload/E-link<br>[% BW @ 1 MHz]<br>(8b/10b encoding)</th><th>Max. Trigger<br>Rate [MHz]</th></tr></thead><tbody><tr><td>L0</td><td>0.94</td><td>5 &times; 10<sup>-3</sup></td><td>37.1</td><td>1.6</td></tr><tr><td>L1</td><td>0.55</td><td>3 &times; 10<sup>-3</sup></td><td>23.4</td><td>2.3</td></tr><tr><td>L2</td><td>0.55</td><td>1.5 &times; 10<sup>-3</sup></td><td>25.4</td><td>2.5</td></tr><tr><td>L3</td><td>0.35</td><td>0.7 &times; 10<sup>-3</sup></td><td>15.4</td><td>2.9</td></tr><tr><td>D0</td><td>0.96</td><td>5.6 &times; 10<sup>-3</sup></td><td>41.6</td><td>1.4</td></tr><tr><td>D1</td><td>0.98</td><td>5.2 &times; 10<sup>-3</sup></td><td>43.6</td><td>1.3</td></tr><tr><td>D2</td><td>1.00</td><td>5.0 &times; 10<sup>-3</sup></td><td>45.7</td><td>1.2</td></tr><tr><td>D3</td><td>1.02</td><td>4.9 &times; 10<sup>-3</sup></td><td>48.4</td><td>1.1</td></tr><tr><td>D4</td><td>1.06</td><td>4.8 &times; 10<sup>-3</sup></td><td>51.2</td><td>1.1</td></tr><tr><td>D5</td><td>1.16</td><td>4.7 &times; 10<sup>-3</sup></td><td>55.3</td><td>1.0</td></tr></tbody></table>
ITk Pixel Detector

For the innermost two layers of the ITk Pixel detector, space and material constraints limit the bandwidth (5 Gb/s) of the copper cables driving the data to the service panels that house the optical transceivers. Thus, the maximum readout rate for complete events is 1 MHz. The total memory is limited by the area of the ASIC and corresponds to a maximum latency of 12.5 µs.

4.1.2 Calorimeter Detectors

The LAr calorimeter will be improved in Phase-II with an electronics upgrade that will provide optimised super cells and full granularity data to the trigger system by means of a new pre-processor (LAr Signal Processor (LASP)). A similar upgrade of the Tile calorimeter readout will use on-detector digitisation and a new backend pre-processor (Tile PrePro-cessor System (TPPr)). Both the LAr and Tile calorimeters expect to implement a 40 MHz readout system for Phase-II. The digitised data will be streamed off-detector at 40 MHz and buffered in modular electronics. This solution is sufficiently fast and with high bandwidth and buffering capability that it places no constraints on the foreseen latencies or rates.

The transmission of high-granularity calorimeter data (all cells above a transverse energy threshold of |*E*<sub>T</sub>| > 2σ) drives the bandwidth requirement for the upgraded TDAQ sys-
tem. The upgraded trigger system must be able to form trigger objects (such as jets) and
topological selections based on this high-granularity data. The LAr and Tile trigger pre-
processors will provide super cell-derived information to the FEX modules of the L0Calo
trigger subsystem. The outermost Tile calorimeter layer can be used to identify muons in
the range |*η*| < 1.3 by better identifying particle energy depositions above the Minimum
Ionising Particle (MIP) threshold.

4.1.3 Muon System

The detailed upgrade plan for the muon system is described in [4.5]. The muon trigger
system consists of the Resistive Plate Chambers (RPCs) in the barrel region (|η| < 1.05) and
Thin Gap Chambers (TGCs) in the endcap region (1.05 ≤ |η| < 2.4) of the ATLAS detector.
After the Phase-I upgrade, the New Small Wheels (NSWs) will maintain high muon trigger
acceptance at high pile-up in the region 1.3 < |η| < 2.4. In Run 4, a system of thin-gap
RPCs will cover the entire inner barrel layer and Monitored Drift Tube (MDT) hits will be
incorporated in the hardware-level trigger.
### Resistive Plate and Thin Gap Chambers

A completely new readout system is planned for both the RPC and TGC detectors for Phase-II. The digitised data will be shipped off-detector at 40 MHz and buffered directly in the L0Muon Trigger Processor modular electronics in USA15. The upgrade is designed to be sufficiently fast and with high bandwidth that it places no constraints on latencies or rates. However, as there will be no distinction between trigger data and readout data paths, the L0Muon trigger processors shall implement the interfaces to the Readout system.

### Monitored Drift Tubes

As the innermost MDT chambers are replaced, no limitations are placed on the upgraded readout electronics. The long drift time (~700 ns) of the MDT chambers is close to the average time between two Level-0 triggers; thus, there is no gain from assigning muon hits to a specific event. As for the RPC and TGC readout the MDT Trigger Processor modules shall provide directly the interface to the Readout system as there are no separate data paths. The baseline readout option is to implement Level-0 buffers in the MDT Trigger Processors, transmitting data packets with all hits belonging to a specific event, and thus allowing data duplication for consecutive triggers. Alternatively, all detector hits from the cavern might be transmitted continuously and a software filter at a higher level in the readout chain shall be implemented with a proper time-tagging reconstruction of the event.

### New Small Wheel

The NSW readout was designed in 2013 according to what at the time was expected to become the ATLAS Phase-II trigger and readout architecture: a two-level hardware trigger scheme with maximum rates of 500 kHz/200 kHz. To cope with the current design, the NSW electronics now support the Phase-II TDAQ specifications, i.e. Level-0 rates of 1 MHz with a maximum latency of 10 µs [4.6]. This requires an increase in the readout bandwidth which will be obtained by increasing the number of data collector chips and optical links, additional to the Phase-I deployment.

The hard limit on the maximum rate is given by the readout rate of the micromega sectors with largest data volume. This is limited to about 1.2–1.3 MHz, without safety factors, in a very limited region of the detector. A safety factor of ~1.3 seems appropriate to take into account the new shielding design. Multiple options are available to mitigate this (very local) issue with no or minimal data loss. Three scenarios allowing a readout rate of ~2 MHz were identified, with a reduced performance in a small part of the forward detector region: (i) using a reduced readout time window, namely 3 Bunch Crossings (BCs) instead of 5, (ii) suppression of Time-to-Digital Converter (TDC) data, or (iii) suppression of empty events.
### 4.1.4 Other Detectors

Including additional subdetectors in Phase-II requires that the TDAQ system architecture provides the necessary infrastructure to allow taking their data. For example, the integration of the HGTD detector in the ATLAS TDAQ system would require dedicated hardware processors and storage of the real-time luminosity measurement through a dedicated data path. Additionally, trigger signals would need to be provided to the Level-0 trigger system thus allowing triggers on minimum-bias events. Supplementary readout capacity for driving the HGTD information will be needed.

## 4.2 Level-0 Trigger Requirements

The Phase-II trigger system shall maintain legacy hardware, where appropriate, accommodate new detectors and exploit the full granularity provided by the detectors.

### Calorimeter Trigger Requirements

Performance requirements on physics objects translate into the following functional and architectural requirements on the trigger processors that use calorimeters information:

* Highly selective single- and multi-lepton triggers are essential to exploit the full physics potential of the HL-LHC. Therefore, a large fraction of the available Level-0 trigger bandwidth shall be allocated to the single-electron trigger of a $p_T$ threshold as low as possible and necessary for the physics programme.

* Additional discriminating variables (e.g., $E_{ratio}$ and topological cluster-based isolation, as described in Section 6.3) that can identify electron candidates are required in order to provide sufficient background rejection (at $\langle\mu\rangle \simeq 200$) while maintaining a low $p_T$ threshold and high trigger efficiency.

* The identification of events with low-$p_T$ multi-jets is particularly challenging in a high-pile-up environment. Sufficient processing power is needed to implement the sophisticated tools that are used in offline event reconstruction: pile-up suppression algorithms, offline-like jet reconstruction algorithms to recover low-$p_T$ jets, and jet energy calibration to improve the momentum resolution.

* The Phase-I FEX modules shall be maintained during the HL-LHC data taking as part of the L0Calo trigger system. A re-optimisation of the algorithms within the available memory resources and the upgraded latency budget of the system will be needed to mitigate higher pile-up conditions.

* The L0Calo trigger system shall be complemented by new processors (Global Trigger) to extend the functionalities and the resource limits of the L0Calo FEXs processors. In particular the Global Trigger shall (i) refine the calculations of the FEX modules by implementing the algorithms aforementioned that are based on higher granularity data,
(ii) apply generalised isolation criteria, and (iii) extend and replace the functionality deployed in the Phase-I topological processors (L1Topo).

* Several physics analyses will benefit from efficient Level-0 reconstruction of forward objects such as jets or electrons using the full granularity of the FCal through dedicated forward FXs modules.

* The missing transverse momentum ($E_T^{\text{miss}}$) trigger performance at Level-1 will benefit from improvements in jet trigger object reconstruction and full-scan tracking to compute the soft term of the $E_T^{\text{miss}}$. In the case of evolution to a dual-level hardware trigger system, tracking information shall be integrated with jet reconstruction in the Global Event Processors (GEPs).

### Muon Trigger Requirements

The momentum resolution of the Level-0 muon trigger is a key attribute in order to select muons with $p_T > 20$ GeV ($p_T > 10$ GeV) for single-lepton (multi-lepton) triggers with a rate smaller than approximately 40 kHz. The spatial resolution of the RPCs and TGCs limits the momentum resolution. In the Level-0 muon trigger system, a momentum resolution of 5% for 20 GeV muons can be accomplished by the reconstruction of straight muon track segments in the MDT chambers.

* To comply with the requirements on resolution and efficiency, MDT's information shall be used at Level-0.

* The trigger chambers shall send the trigger candidate data to the MDT Trigger Processor within $\approx 1.7$ µs, to allow sufficient processing time to the MDT processing.

* The maximum seeding frequency per trigger region handled by a MDT processing element shall be set to a value of 100 kHz.

### Trigger and Readout System Parameters and Requirements

Table 4.2 summarises the key parameters of the design of the TDAQ system in Phase-II, extracted from [4.2]. Their description follows.

1. **Level-0 trigger rate:** A total of 1 MHz is the maximum average Level-0 trigger rate, integrated over many full machine cycles, including gaps. The FE systems and TDAQ detector readout system shall be designed for sustained operation at this rate.

2. **Minimum interval between two Level-0 Trigger Accept (LOA) signals (so-called Level-0 simple deadtime):** LOA signals may occur in consecutive bunch crossings.

3. **Consecutive Level-0 triggers:** at most four LOA in five consecutive BCs are allowed.

4. **Level-0 burst size:** The Level-0 system shall guarantee no more than eight LOA in any period of $0.5$ µs. This is consistent with a deadtime of 0.1% for a 1 MHz Level-0 rate in a simple model (worst case) in which the Global Trigger processes events in parallel. In addition, the Level-0 system shall guarantee no more than 128 LOA in any period
of 90 µs to be consistent with the 0.1% deadtime requirement. This is consistent with an average 1 MHz Level-0 trigger rate and the available buffer size in the front-end ASIC of the strips detector. Note that other limitations can be introduced if needed.

5. **Data transmission to Level-0 Trigger Processors:** The skew in the arrival times of the different calorimeter and muon detector data at the Level-0 Trigger Processors shall be accommodated by dedicated buffers prior to transmission by the relevant subdetector systems or by buffers at the input stage of the relevant Trigger Processors (L0Calo FEXs and Global Trigger modules for the calorimeter, and L0Muon Sector Logic, MDT Trigger Processors for the muon detectors). For the calorimeters, the skew has a maximum possible value of 16 BCs. For the muon detectors the skew is determined by the maximum drift time in the MDT detectors and the fast arrival of the RPC and TGC trigger objects, calculated in Sector Logic modules, into the MDT Trigger Processors.

6. **Level-0 latency:** The Level-0 system shall be designed to have a fixed maximum latency, as defined in Section 5.2.8, of 10 µs.

7. **Maximum deadtime value:** Deadtime is the fraction of triggers vetoed by the CTP. A maximum of one percent (1%) deadtime is required for ATLAS as a whole. The 0.1% deadtime per subdetector system is derived by considering all the different ATLAS subdetectors planned to operate during the HL-LHC. A subdetector system shall not veto more than 0.1% of the triggers by the assertion of the BUSY signal and/or by the algorithm implemented in the CTP that specifically vetoes triggers to protect it (a.k.a. complex deadtime). The subdetector systems shall be responsible of defining buffer and/or pipeline dimensions and data transmission speeds in accordance with this specified deadtime.

## Timing and Control Distribution Requirements

Timing, Trigger, and Control (TTC) signals need to be distributed to the common elements (FELIX) of the readout system and other subdetector-specific electronics. Based on the experience from the current implementation, the timing signals must include the 40 MHz beam-synchronous clock derived from the LHC, which is used to clock the subdetector front-end electronics, as well as the ORBIT signal that is synchronous with the LHC turns. Trigger signals must include the L0A signal, along with associated information, such as a L0A counter, a bunch-crossing identifier, type of trigger decision, etc. In addition, control signals and data, sent synchronously or asynchronously with the beam will be needed for specific uses. During physics data-taking, the Central Trigger will act as TTC master, while for calibration and test runs the system needs to be partitioned and controlled by Local Trigger Interface (LTI) modules. The transmission of the downlink TTC signals has to be done with low latency, low jitter, and the quality of the transmitted clock has to be compatible with the very demanding Multi-Gigabit Transceivers (MGT), which are used everywhere along the trigger and readout paths. In the opposite direction, BUSY signals have to be collected from the common readout elements or subdetector-specific electronics
<table><caption>Table 4.2: List of the main trigger and readout parameters in the baseline architecture. Latency values are given with respect to the original BC. The values indicated in this table represent the requirements for the interfaces between the detector-specific FE and the TDAQ system. The quoted values include contingency and margins.</caption><thead><tr><th>Parameter</th><th>Phase-II value</th></tr></thead><tbody><tr><td>Clock frequency</td><td>40.08 MHz</td></tr><tr><td>Level-0 trigger rate</td><td>1 MHz</td></tr><tr><td>Minimum interval between two L0A signals</td><td>0 BC</td></tr><tr><td>Consecutive Level-0 triggers</td><td>≤ 4 L0A in 5 BC</td></tr><tr><td>Level-0 burst size</td><td>≤ 8 L0A in 0.5 µs</td></tr><tr><td>Maximum skew between all calorimeter inputs to L0Calo FEXs</td><td>≤ 128 L0A in 90 µs</td></tr><tr><td>Level-0 latency</td><td>10 µs</td></tr><tr><td>Calorimeter data reception in L0Calo & L0Muon processors</td><td>1.7 µs</td></tr><tr><td>High Granularity Calorimeter data reception in Level-0</td><td>1.7 µs</td></tr><tr><td>Seeding Muon detector data reception in L0Muon</td><td>1.7 µs</td></tr><tr><td>Precision Muon detector data reception in L0Muon</td><td>2.8 µs</td></tr><tr><td>Deadtime</td><td>&lt;0.1% per detector system</td></tr></tbody></table>

and propagated up to the central trigger. Details of the timing and control signals which will be distributed, along with all possible readout architecture that will co-exist in ATLAS, are described in the Detector FE Interface Requirement Document [4.2].

The on-detector electronics will always require the Clock and ORBIT signals, even if they get L0A signals as well. All event fragments carry Bunch Crossing IDentifier (BCID) information that is derived from these signals. Detectors read out on Level-0 can also have a Level-0 identifier. Basically, all detectors send data off detector at the bunch-crossing rate of 40 MHz, except for the ITk strips and pixels due to technical and financial reasons, and the NSW because of constraints from the legacy system. Readout to FELIX from the FE ASICs (ITk and NSW) or from off-detector electronics (all other detectors) is generally done after receiving the L0A signal.

### Hardware Requirements

The hardware requirements for the Level-0 trigger sub-systems are specified as follows:

* Level-0 Trigger (L0) Trigger sub-systems shall be specified and implemented assuming ATCA as hardware platform.

* Blade design shall be compatible with PICMG-3.0 Revision-3.0 standard.

* No more than 4 mezzanines compatible with PICMG AMC.0 R2.0 specifications shall be accommodated on a blade.

* CERN-developed IPMI Management Controller (IPMC) shall be used for basic blade control and configuration at power up through the ATCA shelf manager.
* Blade configuration and control shall be implemented through a standard Network interface using a System-on-Chip (SoC)-based solution as detailed in Chapter 15. The configuration of some of the Phase-I upgrade subsystems (e.g. eFEX) is implemented through the IPBUS protocol, which shall be supported during the HL-LHC lifetime.

* DCS interfaces shall be implemented through a standard Network interface using a CERN-developed IPMC for basic blade monitoring and control at power up through the ATCA shelf manager, and a SoC-based solution as mentioned above.

* Shelf configuration shall not exceed 2 Hub slots and 12 node slots for a total maximum allowed power dissipation of 7.5 kW including the shelf manager, switch and cooling fans at maximum power.

* ATCA blade power consumption shall not exceed 400 W.

* Rear Transition Module in the HTT (RTM) module shall not exceed 50 W in power consumption.

## 4.3 DAQ Requirements

The DAQ system will receive and deliver data via links with protocol and bandwidth suitable for individual detector subsystems. The capacity should accommodate the significantly increased trigger rate of 1 MHz, and the much larger event size of about 5.2 MB, with enough flexibility to allow detector subsystems to operate at different event rates and to adjust data content with different run conditions.

Overall standardisation of all basic common elements will minimise cost, maintenance and evolution over the 10–20 years of operation in the HL-LHC period. Effort is required from an early stage to decompose the project into functional elements and their interfaces and to define standard common elements, interfaces and protocols for each logical element.

* The DAQ system shall be scalable with respect to the trigger rate and the luminosity, capable of handling detector data input of about 5.2 TB/s. The system should take advantage of the technology advances in commodity information technology software and hardware, given the advantages of being cheaper and requiring less maintenance than any custom hardware.

* The Readout and Dataflow subsystems shall sustain high throughput combining the input from detector front-end electronics (up to about 5.2 TB/s) and the output to the Event Filter (up to about 2.6 TB/s) at the required trigger rate, and be able to deal with high rate fluctuations without causing large congestion and data loss.

* The Readout subsystem shall be designed to have a common interface to the detector front-end that accommodates the varieties of protocols and bandwidths of the front-end links of each subdetector system. In particular, it should deliver control and configuration information to the detector front-end via the radiation tolerant lpGBT link (uplink bandwidth of 9.6 Gb/s and downlink bandwidth of 2.5 Gb/s), and read out data with the lpGBT protocol or other specific protocols suitable for individual
subdetector systems, e.g., dedicated protocol to be developed for ITk Pixel and the Full Mode protocol for LAr trigger electronics installed in USA-15.

* The Readout subsystem interface to the detector front-end shall route raw data for further processing via a standard common network protocol, access to which should make it possible for detector-specific data handling and monitoring to be performed.

* The system shall be capable of executing also detector-specific control and configuration operations, interfacing to the common ATLAS DCS system.

* It is essential to have sufficient storage to enable the dynamic decoupling of real data taking and the Event filter processing.

* Based on operational experience from Run 1 and Run 2 the system has to be able to operate for up to 48 hours without access to the offline permanent storage. At the average throughput of about 60 GB/s of uncompressed data this requires a storage volume of 10 PB.

## 4.4 Event Filter Requirements

The EF will be designed to work at a luminosity of $7.5 \times 10^{34} \text{cm}^{-2}\text{s}^{-1}$. The scale of the EF compute requirements derive from this as they depend on the input rate, which is the accept rate of the Level-0 trigger, and the level of pile-up. There is a close coupling between the scale of the Dataflow and EF systems in this respect.

* The EF system shall be designed to sustain a maximum input rate of 1 MHz.

* The EF system shall be designed to select events with a maximum output rate of 10 kHz.

* The EF trigger efficiency and rejection requirements for all signatures are derived from the physics requirements described in Section 2.

* EF algorithms and selections shall be designed to maximise efficiency with respect to offline reconstruction and minimise systematic bias from the trigger.

* Many of the initial fast rejection techniques presently used in the Run 2 HLT are implemented in the Level-0 hardware trigger in Phase-II. Therefore, more sophisticated algorithms, identical or as close as possible to the offline reconstruction methods, are needed earlier in the EF selection. Where necessary innovative approaches shall be developed to reach the required performance and fulfill the time constraints.

* Experience from offline reconstruction shows that the effects of pile-up on reconstruction resolution and quality can be mitigated by using vertices and tracks. This is especially important for hadronic triggers, for which tracks were not used in Run 1 or Run 2 for the purpose of pile-up suppression due to processing or readout constraints. The EF must be capable of reconstructing vertices and tracks as needed for pile-up suppression.

* Reconstruction algorithm times tend to increase with luminosity, in some cases much worse than linearly, posing a tough challenge to the EF software. The model that has
been developed to estimate the compute requirements at $\langle\mu\rangle = 200$ assumes that most
time-consuming algorithms can achieve linear scaling and speed can be improved
over today's measured performance, so these become requirements.

* In particular, tracking in a high pile-up environment is computationally expensive: given the above need for tracking, there is a strong requirement to reduce this cost through both improvements to software tracking and some form of hardware track-ing.

* EF selection shall follow the principles of early rejection and delaying full event data access, to reduce the event building rate in the Dataflow system and the volume of data that the Storage Handler (Storage Handler) must hold, to below the need for full event at 400 kHz.

* Event data unpacking in the EF is time critical: the data format and unpacking code need to be developed very closely between the detector and EF experts.

* Commodity processing technology will continue to evolve over the next 10 years. The EF software shall be prepared to make efficient use of many-core processors, which is the current industry direction. Note that the Phase-I upgrade will be an excellent starting point from which to optimise this for Phase-II.

Hardware Tracking Requirements

There are two complementary tracking requirements for the baseline TDAQ system: fast
regional tracking and more precise global tracking.

* Regional tracking is required at the full Level-0 rate of 1 MHz to provide tracks for fast initial rejection of single high-$p_T$ lepton and multi-object triggers in the EF. The tracks will be used in combination with information from the Global Trigger. Tracks are needed for all charged particles with $p_T > 2$ GeV and $|\eta| < 4.0$. Regions will be defined in the EF based on objects identified by the Level-0 trigger and, on average, will represent less than 10% of the full event.

* Global tracking for b-jet identification requires reconstruction of all charged particles with $p_T > 1$ GeV in an event within $|\eta| < 4.0$, with track quality and minimum $p_T$ similar to offline track reconstruction [4.3].

* Global tracking for soft jets, calculation of the $E_T^{\text{miss}}$ soft term and pile-up correction and mitigation requires reconstruction of all charged particles with $p_T > 1$ GeV in an event within $|\eta| < 4.0$.

* The global tracking $d_0$ and $z_0$ resolutions shall be no more than twice the respective offline resolutions with digital clustering, and the fake rate shall be at the percent level or lower.

The following requirements are related to the interface between the EF and ITk.
* For regional tracking requests, the EF will determine the regions to be requested from the Level-0 data and will map these to parts of the ITk data and the relevant HTT units.

* The EF will obtain and send the relevant ITk data as part of the hardware tracking request.

* A HTT interface is required to accept requests for regional and full tracking from EF processes and relay them synchronously to the relevant boards in the associated HTT unit.

## References

[4.1] ATLAS Collaboration, *ATLAS Phase-II Upgrade Scoping Document*, Tech. Rep. CERN-LHCC-2015-020. LHCC-G-166, CERN, Geneva, Sep, 2015. https://cds.cern.ch/record/2055248.

[4.2] F. Lanni et al., *Interfaces with Detector Front-End Systems. Requirement Document for HL-LHC*, Tech. Rep. ATL-DA-ES-0051 v.1, EDMS Id 1563801 v.1, CERN, Geneva, March, 2016. https://edms.cern.ch/document/1563801.

[4.3] ATLAS Collaboration, *Technical Design Report for the ATLAS Inner Tracker Strip Detector*, Tech. Rep. CERN-LHCC-2017-005, CERN, Geneva, Apr, 2017. https://cds.cern.ch/record/2257755.

[4.4] ATLAS Collaboration, *Technical Design Report for the ATLAS Inner Tracker Pixel Detector*, Tech. Rep. CERN-LHCC-2017-021, CERN, Geneva, (in preparation).

[4.5] ATLAS Collaboration, *Technical Design Report for the Phase-II Upgrade of the ATLAS Muon Spectrometer*, Tech. Rep. CERN-LHCC-2017-017. ATLAS-TDR-026, CERN, Geneva, Sep, 2017. https://cds.cern.ch/record/2285580.

[4.6] ATLAS Collaboration, *ATLAS New Small Wheel Technical Design Report*, Tech. Rep. CERN-LHCC-2013-006. ATLAS-TDR-020, CERN, Geneva, Jun, 2013. https://cds.cern.ch/record/1552862.
# 5 Description of the Baseline System

This Chapter provides a functional overview of the systems within the TDAQ Phase-II Upgrade Project: the Level-0 Trigger System, the Data Acquisition System (DAQ), and the Event Filter (EF) System. An overview of the subsystems within each system is presented here. Detailed descriptions of the system components and hardware design considerations are presented in dedicated chapters in Part II of this document.

## 5.1 Functional overview

The functional overview of the baseline TDAQ system planned for Phase-II is shown in Fig. 5.1.

The data inputs from the detectors are categorised in the figure as Inner Tracker (which includes the ITk pixel and strip detectors), Calorimeters (the LAr and Tile calorimeters), and Muon System (including MDT, RPC, TGC and NSW). Detector-specific off-detector electronics for both readout and trigger data preparation are included as part of the detector systems.

The Level-0 Trigger system is made up of the L0Calo, L0Muon, Global Trigger, and Central Trigger subsystems. L0Calo and L0Muon are similar in functionality to their Phase-I predecessors; they use calorimeter and muon system information at 40 MHz, respectively, to apply an initial event selection and to identify features to be examined at the subsequent trigger level. The L0Calo system is based on the legacy Phase-I L1Calo system with minor changes, and uses coarse-granularity calorimeter data to identify electron, tau lepton, and jet candidates, and to calculate $E_T^{miss}$. A dedicated "forward" Feature Extractor (fFEX) is planned to ensure efficient electron identification in the region $3.2 < |\eta| < 4.0$. Each component of the L0Muon subsystem is upgraded compared to the corresponding system in Phase-I, receiving data from all of the muon subsystems and a subset of the Tile Calorimeter information to identify muon candidates. New features of the L0Muon system for Phase-II are the inclusion of precision MDT momentum measurements as well as new RPC inner stations to improve the muon trigger coverage. The MUCTPI provides an interface between the barrel and endcap components of the L0Muon system on one hand, and the Global Trigger and CTP on the other. It identifies muon candidates that have been counted twice in the L0Muon system (overlap removal) and calculates multiplicities for various transverse-momentum thresholds.
<figure><img src="image_55.png" /><figcaption>Figure 5.1: Overall baseline design of the TDAQ system in Phase-II. The black dotted arrows indicate the Level-0 dataflow from the detector systems to the Level-0 trigger system (composed of the L0Calo, L0Muon, MUCTPI, Global Trigger, and CTP) at 40 MHz, which must identify physics objects and calculate event-level physics quantities within 10 µs. The result of the Level-0 trigger decision (LOA) is transmitted to the detectors as indicated by the red dashed arrows. The resulting trigger data and detector data are transmitted through the DAQ system (made up of FELIX, the Data Handlers, and the Dataflow subsystem) at 1 MHz, as shown by the black solid arrows. Direct connections between each Level-0 trigger component and the Readout system are suppressed for simplicity. The EF system is composed of a processing farm and a hardware-tracking subsystem (HTT) that must reduce the event rate to 10 kHz. Events that are selected by the EF trigger decision are transferred for permanent storage.</figcaption></figure>
The Global Trigger is a new subsystem of the Level-0 Trigger system, which will perform offline-like algorithms on full-granularity calorimeter data, for example using information from LAr first-layer strips to better reject $\pi_0$ in $e/\gamma$ identification and making topological clusters for refined jet algorithms (anti-$k_t$) and pile-up subtraction. It will also identify topological signatures that can include a wide variety of four-vector combinations involving sums, angles and invariant masses. The L0Calo and L0Muon/MUCTPI subsystems send their selected objects to the Global Trigger, including spatial locations, reconstructed energy/momentum values and discriminant variables. These objects are then combined with the results of the Global Trigger calorimeter processing to refine the e/gamma, tau, muon and jet selections. The CTP forms the final Level-0 decision, taking into account the trigger menu configuration, prescale factors, and dead-time requirements. This decision is transmitted as a L0A signal via LTIs, the TTC distribution network, and FELIX, to the detector systems.

Following the Level-0 trigger decision, detector data are transmitted over custom point-to-point serial links to the Front-End Link eXchange (FELIX) subsystem, the first element of the Readout subsystem within the DAQ system. FELIX provides a common interface between the detector-specific custom point-to-point serial-links and the commodity multi-gigabit data network downstream. Along the network, data are received by the Data Handlers, where detector-specific processing, e.g. formatting and/or monitoring, can be implemented before buffering data in the Dataflow subsystem. The Readout subsystem is designed to handle 1 MHz event rate, for a total bandwidth of 5.2 TB/s. The Dataflow subsystem buffers, transports, aggregates, and compresses event data for utilisation in the EF System, which is effectively shielded from the underlying distributed storage system. Data are buffered here while waiting for the EF selection results.

A large EF processor farm is needed to cope with the 1 MHz input rate; commodity-CPU-based event processing will be aided by the new HTT subsystem, which is designed to provide fast hardware-based track reconstruction. Regional tracking allows a fast initial rejection in the EF of single high-$p_T$ lepton and multi-object triggers from background processes, to reduce the rate to around 400 kHz. This system is specified to operate at 1 MHz and use up to 10% of the ITk data, by selecting tracking modules in regions based on the results of the Level-0 trigger system. Software-based reconstruction will follow to achieve further rejection. This will be aided by global tracking at around 100 kHz using the HTT again, but this time to produce tracks closer to offline quality, suitable for b-jet tagging, $E_T^{\text{miss}}$ soft term calculation, soft jets and pile-up suppression. The rates of Level-0 triggers for which regional or global tracking are needed are shown in Section 6.11.

Events selected by the EF are then transferred to the permanent storage of the ATLAS offline computing system. The raw output event size is expected to be 6 MB, and the total trigger output is expected to be 10 kHz; thus, the total bandwidth out of the system is 60 GB/s.
# 5.2 The Level-0 Trigger System

A diagram illustrating the details of the Level-0 Trigger System is shown in Fig. 5.2. The functionality and hardware implementation of each Level-0 Trigger subsystem (L0Calo, L0Muon, Global Trigger, and Central Trigger) are summarised briefly in this section.

### 5.2.1 Level-0 Calorimeter Trigger

Table 5.1 contains the list of all Level-0 Calorimeter trigger components in ATLAS showing, per subsystem, the list of Trigger Objects identified, the approximate detector granularity used and the coverage region in $|\eta|$.

<table><caption>Table 5.1: List of Level-0 Calorimeter trigger components showing, per subsystem, the Trigger Objects identified, the detector granularity used and the $\eta$ coverage. Detector granularities used include either Full detector cells, Super Cells or coarser $\Delta\eta \times \Delta\phi$ granularity.</caption><thead><tr><th>Subsystem</th><th>Trigger Object</th><th>Approximate Granularity</th><th>Coverage |η|</th></tr></thead><tbody><tr><td>eFEX</td><td>e/γ, τ</td><td>Super Cells (10 in 0.1 × 0.1)</td><td>&lt; 2.5</td></tr><tr><td>jFEX</td><td>τ, jet, E<sub>T</sub><sup>miss</sup></td><td>0.1 × 0.1</td><td>&lt; 2.5</td></tr><tr><td>jFEX</td><td>τ, jet, E<sub>T</sub><sup>miss</sup></td><td>0.2 × 0.2</td><td>2.5 – 3.2</td></tr><tr><td>jFEX</td><td>τ, jet, E<sub>T</sub><sup>miss</sup></td><td>0.4 × 0.4</td><td>3.2 – 4.9</td></tr><tr><td>gFEX</td><td>Large-R jet, E<sub>T</sub><sup>miss</sup></td><td>0.2 × 0.2</td><td>&lt; 4.9</td></tr><tr><td>fFEX</td><td>e/γ</td><td>Full detector EMEC, HEC, FCal</td><td>2.5 – 4.9</td></tr><tr><td>fFEX</td><td>jet</td><td>Full detector FCal</td><td>3.2 – 4.9</td></tr></tbody></table>

L0Calo is based on the Phase-I L1Calo system described in the TDAQ Phase-I TDR [5.1]. In this system, separate LAr and Tile calorimeter data streams with coarse granularity (compared to offline) are sent to FPGA-based Feature Extractors (FEXs), which find electron, photon, and tau lepton candidates (eFEX), tau leptons, jets and $E_T^{\text{miss}}$ (jFEX), and large-R jets and $E_T^{\text{miss}}$ (gFEX). The LAr Calorimeter inputs to the system are maximally ten super cells per region of $0.1 \times 0.1$ in $\eta \times \phi$ for $|\eta| < 2.5$, and have coarser granularity for larger $|\eta|$ values. The Tile Calorimeter inputs to the system are $0.1 \times 0.1$ in $\eta \times \phi$, summed in depth. The output of the L0Calo subsystem is a set of electron, photon, tau lepton, jet, and $E_T^{\text{miss}}$ trigger objects that are sent to the Global Trigger. The fFEX will handle full granularity LAr in the region $2.5 < |\eta| < 4.9$ ($3.2 < |\eta| < 4.9$) and reconstruct forward electromagnetic (forward jet) trigger objects.

The interfaces to L0Calo from other detector systems and from L1Calo to other components of TDAQ are the following:
<figure><img src="image_56.png" /><figcaption>Figure 5.2: Diagram of the Level-0 Trigger architecture. The arrows indicate the type of object that is transmitted between each component of the system. Super cell energies are sent to the eFEX, while coarser granularity, based on sums of super cells energies, are sent to the jFEX and gFEX, respectively, as is done in the Phase-I system. Information from calorimeter cells with $|η| > 2.5$, without an energy threshold, is sent to the fFEX. Tile calorimeter information from the outermost layer is used in coincidence with muon trigger primitives from the RPC and TGC in the Barrel and Endcap Sector Logic components, respectively. Hit information from the NSW and MDT are sent to their corresponding Trigger Processors. The MDT Trigger Processor refines the momentum measurement for muon candidates determined by the Sector Logic components; the resulting muon candidates are transmitted to the MUCTPI for overlap removal and multiplicity determination. Elementary calorimeter cells above a transverse energy threshold of $|E_T| > 2σ$ are sent to the Global Trigger for use in topological clustering and other refined algorithms. Trigger Objects (TOBs) are formed by each of the FEXs, as well as the MUCTPI, which are refined by the Global Trigger. The CTP combines information from the Global Trigger and MUCTPI, consisting of trigger algorithm flags and multiplicities of selected objects, to make the final Level-0 trigger decision.</figcaption></figure>

* LAr EM, EMEC, HEC calorimeter pre-processors called LAr Digital Processing System (LDPS) and LASP, carrying Super Cell and Full granularity detector data to L0Calo, respectively.

* Global Trigger, to which Trigger Objects are sent for refined processing.
* CTP, to be used for commissioning of L0Calo before the Global Trigger final commissioning has been completed.

* Readout System, carrying input, output and intermediate processing data through FELIX.

* Timing and Control distribution upstream and downstream information through FE-LIX.

* Control and Configuration via commodity network (Ethernet).

* DCS and Monitoring information through FELIX.

* DCS interface, common to all ATCA hardware.

The system uses ATCA blades as the standard processing platforms. Dedicated hardware is designed and already deployed in the Phase-I upgrade for eFEX, jFEX and gFEX subsystems, while a new design is foreseen for the fFEX. The full Level-0 Calorimeter trigger is deployed in 5 ATCA shelves, two for the eFEX, one for the jFEX, one for the gFEX and one for the fFEX subsystems.

### 5.2.2 Level-0 Muon Trigger

Table 5.2 contains the list of all the Level-0 Muon trigger components in ATLAS showing, per subsystem, the detector data used and coverage region in $|η|$.

<table><caption>Table 5.2: List of all Level-0 Muon trigger components showing, per subsystem, the list of Trigger Objects processed and identified. All subsystem use information from multiple detectors: Muon Barrel uses RPC, MDT and Tile Outer layer, while the Muon Endcap uses TGC, MDT, NSW, RPC and Tile outer layer.</caption><thead><tr><td>Subsystem</td><td>Granularity</td><td>Coverage |η|</td></tr></thead><tbody><tr><td>NSW processor</td><td>Full NSW detector</td><td>1.3 – 2.4</td></tr><tr><td>MDT processor</td><td>Full MDT detector</td><td>&lt; 2.4</td></tr><tr><td>Barrel Sector Logic</td><td>Full RPC and Tile, MDT</td><td>&lt; 1.05</td></tr><tr><td>Endcap Sector Logic</td><td>Full TGC, Tile, RPC, NSW, MDT</td><td>1.05 – 2.4</td></tr></tbody></table>

The entire muon trigger electronics and readout chain will be replaced in Phase-II, except for some parts of the on-detector front-end electronics<fnref n="1" />. All data from the barrel (RPC) and endcap (TGC) detectors will be transmitted off-detector where the full information will be available for trigger processing. In such a scheme, more refined and flexible algorithms can be used compared to the present ones based on simple coincidences, which are limited by on-detector connectivity. In the NSW detector region ($1.3 < |η| < 2.7$), both the MM and sTGC chambers take the dual role of trigger and precision chambers. Muon trigger

<footnote n="1">¹ The TDAQ responsibility begins at the USA15 counting room. Upstream components are the responsibility of the Muon detector community.</footnote>
primitives (track segments) from these detectors will be combined with TGC hits to provide
the endcap trigger candidates in the region (1.3 < |η| < 2.4)<fnref n="2" />.

The Barrel Sector Logic board will take input data at each bunch crossing from the RPC on-detector electronics and the digital readout from the outermost Tile Calorimeter cells. The Endcap Sector Logic board will take input data at each bunch crossing from the TGC on-detector electronics, the NSW MM and sTGC chambers via the NSW Trigger Processor, digital readout from the outermost Tile Calorimeter cells, and the thin-gap RPC triplet in the barrel-endcap transition region. Both barrel and endcap muon candidates are formed in FPGA-based Sector Logic boards; the results are sent to the Global Trigger via the MUCTPI. After a L0A, the digital readout is sent to the Readout subsystem via FELIX.

The MDT readout chain will be replaced, including the front-end cards (mezzanine cards) where the hit buffers reside. This replacement, along with the increased L0 latency, also presents the opportunity to use in the L0 trigger the precision coordinates measured by the MDT to improve the quality of trigger candidates provided by the RPCs in the barrel and by the TGCs plus NSW in the endcaps. The MDT processing will be seeded by the Barrel and Endcap Sector Logic boards, which will identify potential muon candidates. Pattern recognition and tracking will follow, carried by MDT-dedicated processors. The refined muon candidate will be sent back to Barrel and Endcap Sector Logic modules for the final selection of candidates to be sent to the MUCTPI subsystem. Two implementations are being considered for the hit pattern matching functionality of the MDT Trigger Processors: a baseline design using FPGAs and an alternative one using AM chip. The design considerations for these potential implementations are described in more detail in Section 8.6.

The L0Muon interfaces from other detector systems and to other components of TDAQ are
the following:

* the detector front-end links for all muon detectors, RPC, TGC, MDT, NSW, carrying full granularity data to L0Muon processors;

* Tile pre-processor links, carrying muon tag information to the Barrel and Endcap Sector Logic boards;

* the MUCTPI, which is the interface between the L0Muon system and the Global Trigger and CTP;

* the Readout System, transmitting full detector data, input, output and intermediate trigger processing data through FELIX;

* the timing and control distribution (upstream and downstream) through FELIX;

* the control and configuration interface via the commodity network (Ethernet);

* the DCS and monitoring information via FELIX; and

* the DCS interface, which is common to all ATCA hardware.

The system uses ATCA blades as the standard processing platforms. New dedicated hardware is designed for the Phase-II upgrade. The same ATCA blade design is foreseen to be

<footnote n="2">² Studies quantifying the implications of extending the trigger coverage for muons in the region $2.4 < |η| < 2.7$ are ongoing. Muon trigger coverage out to $|η|$ of 2.4 is the baseline configuration.</footnote>
used for Barrel and Endcap Sector Logic, while a dedicated blade design is foreseen for MDT. It is not yet clear whether NSW will use the existing Phase-I ATCA blade or a new one: some work is outstanding before the baseline solution is chosen. The full Level-0 Muon trigger is deployed in 15 ATCA shelves, 2 dedicated to the NSW processors, 6 dedicated to the MDT processors, 3 for the Barrel and 4 for the Endcap Sector Logic.

### 5.2.3 MUCTPI

The MUCTPI aggregates and merges the trigger information from the barrel and endcap muon systems before passing it to the Global Trigger and the CTP.

The MUCTPI interfaces only to other components of TDAQ, as follows:

* the Barrel and Endcap Sector Logic modules, from which muon candidates are received for further processing, e.g. overlap removal between the barrel and endcap Sector Logic modules;

* the interface to the Global Trigger, to which muon candidates are transmitted;

* the interface to the CTP, to which muon multiplicity information for various $p_T$ thresholds is transmitted;

* the interface to the Readout System, transmitting input, output and intermediate trigger processing data through FELIX;

* the timing, trigger and control distribution;

* the control and configuration interface via the commodity network (Ethernet);

* the DCS and monitoring information via FELIX; and

* the DCS interface, which is common to all ATCA hardware.

The system uses ATCA blades as the standard processing platforms. The current baseline foresees the use of two blades designed for the Phase-I upgrade. The MUCTPI sub-system is deployed in one ATCA shelf.

### 5.2.4 Global Trigger

The Level-0 trigger functionality of the Global Trigger complements the L0Calo trigger objects with additional high-granularity energy data coming directly from upgraded calorimeter pre-processors (the LASP and TPPr). This allows the implementation of offline-like algorithms such as: topological clustering, refined electron and photon identification, tau lepton identification, lepton isolation, calorimeter-based pile-up suppression, sophisticated jet-finding, and dedicated exotic-object selection. Furthermore, the Global Trigger will replace and extend the functionality of the L1Topo system, applying topological selections (such as angular requirements) to trigger objects.
The hardware implementation of the Global Trigger consists of three primary components: a Multiplexer Processor (MUX) layer, a GEP layer, and a demultiplexing Global-to-CTP Interface (CTP Interface), all of which have identical hardware composed of ATCA blades and FPGAs with many multi-gigabit transceivers. The calorimeter detector subsystems, FEXs, and MUCTPI provide serial data for each bunch crossing to the MUX layer. These signals are then time-multiplexed and the signals for a given event are transported to a single GEP node that executes the algorithms described above. Finally, the results are sent to the CTP through the CTP Interface. There are two main advantages of the time-multiplexed architecture. First, the event processor is decoupled from the LHC bunch-crossing rate, allowing the use of asynchronous and high-level algorithms that are impossible in the Phase-I hardware trigger. Second, this implementation removes the limitation on the number of TOBs from the FEXs that are present in the Phase-I hardware trigger. Common hardware modules are implemented across the Global Trigger system, minimising the complexity of the firmware and simplifying the system design and long-term maintenance.

The interfaces between Global Trigger and other detector systems and components of TDAQ are as follows:

* the interfaces from the calorimeter front-end electronics, which send full-granularity cell energies ($|E_T| > 2\sigma$) every LHC bunch crossing;

* the interfaces from the L0Calo FEXs, which send TOBs every LHC bunch crossing;

* the interface from the MUCTPI, which sends TOBs every LHC bunch crossing;

* the interface to the CTP, which receives a 1024-bit TIP (Trigger Inputs) consisting of flags and multiplicity values from the Global Trigger algorithms every LHC bunch crossing;

* the interfaces to the FELIX for the readout of TIPs, trigger algorithm results, and error reporting;

* the interface from the FELIX containing clock, configuration, per-event TTC information, and event accept signals; and

* the DCS interface that is common to all ATCA hardware.

For every L0A the Global Trigger will produce a compact data structure mapping the TIP onto the TOBs which caused those TIP bits to be fired; this will be included in the readout data. All intermediate objects produced by the algorithms will also be read out, but as with the L0Calo FEX modules, the full input data will in general not be read out.

### 5.2.5 Central Trigger Processor

The CTP makes the final L0A decision, aligning and combining digital trigger inputs from the Global Trigger, MUCTPI, the legacy Phase-I L1Topo system, and various forward detectors and subdetector calibration systems, as well as introducing deadtime and applying prescales as required. The L0A signal is then transmitted to the subdetectors via the LTIs.

The CTP interfaces only to other components of TDAQ, as follows:
* optical inputs from the MUCTPI and legacy Phase-I L1Topo system;

* optical inputs from the Global Trigger, receiving trigger algorithms flags to be processed for the final Level-0 decision;

* electrical trigger signals from various forward detectors and subdetector calibration systems;

* the interface to the Readout System, transmitting input, output and intermediate trigger processing data through FELIX;

* the timing and control distribution to the detectors and all TDAQ subsystems through the LTIs;

* the LHC machine interface for the reception of the clock and all LHC-related signals;

* the control and configuration interface via the commodity network (Ethernet);

* the DCS and monitoring information through FELIX; and

* the DCS interface, which is common to all ATCA hardware.

The system uses ATCA blades as the standard processing platforms. The current baseline foresees the use of three types of blades designed specifically for the Phase-II upgrade, one dedicated to the machine interface, one input blade for all other inputs and a core processor blade. The full CTP is deployed in one ATCA shelf.

### 5.2.6 Trigger, Timing and Control System

The TTC network transmits the 40 MHz beam synchronous clock with low jitter, the L0A decision with fixed latency, as well as additional timing information including the synchronous turn signal (bunch counter reset), and other synchronous or asynchronous timing and control signals. In the opposite direction, Busy signals from the subdetector back-end electronics are collected via the TTC Busy network. The detailed TTC information is described in the Detector-TDAQ Interface document [5.2].

As shown in Fig. 5.3, the TTC network has a tree-like structure starting from the CTP, where there is one optical output link per subdetector partition. The CTP receives the relevant timing signals from the Machine Interface Module. The point-to-point output links connect to LTI boards close to the subdetector FELIX components. The LTIs provide an interface for the TTC signals between the CTP and subdetector front-end electronics via FELIX. In addition, the LTI modules can mimic the CTP functionality for standalone subdetector running that is used for detector development, commissioning, and calibration. They can also store and send detector commands and data for configuration and calibration.

From the LTIs, PONs implement a Point-to-Multipoint architecture in which fibre optic splitters are used to enable a single optical fibre to serve multiple end-points. A PON consists of a top node, called Optical Line Terminal (OLT), one or more destination nodes, called Optical Network Units (ONUs) and the fibres and splitters between them. Time-division multiplexing is implemented to collect the Busy signals from the FELIX I/O cards.

The TTC interfaces to detectors and to other components of TDAQ are as follows:
<figure><img src="image_57.png" /><figcaption>Figure 5.3: *The Level-0 Timing and Control paths. Point-to-Point (P2P in the figure) and PON links are used in the TTC network.*</figcaption></figure>

* the LTI PON interfaces and optical fibre trees, to FELIX or detector-specific clients;

* an interface from the CTP, receiving all relevant TTC signals;

* electrical trigger signals from the local TTC inputs, to be used for commissioning purposes or during tests;

* the control and configuration interface to subsystem specific elements via the commodity network (Ethernet);

* the LTI control and configuration interface via the commodity network (Ethernet); and

* the DCS interface, which is common to all ATCA hardware.

The system uses ATCA blades as the standard processing platforms. The current baseline foresees the use of one LTI blade designed specifically for the Phase-II upgrade. The number of LTI blades depends on the detector partitioning; based on experience from Run 2, we currently assume a total of 36 units will be distributed in shelves belonging to detector or TDAQ subsystems.
### 5.2.7 Technical implementation and system size

The Level-0 system design aims to maximise the processing away from the detector in order to ease maintenance, accessibility and the possibility of future upgrades. In addition, the number of boards to be designed is minimised as much as possible. Designing and writing firmware will be managed similarly to designing and building hardware. Interfaces on the boundaries of subsystems are defined at an early stage in order to optimise the partitioning and design efforts of the many groups participating in the construction. ATCA technology is adopted as the baseline for all detector and trigger electronics, and PCIe cards are used when it is necessary to interface to high performance networks, conforming to industry standards. Point-to-point high speed links and PON technology are used for all trigger data transmission and broadcasting needs.

The overall size of the Level-0 Trigger System, in terms of the number of boards and number of links corresponding to each hardware component, is summarised in Table 5.3. For these components, the output links to the readout path are not included. This table provides also a list of components which are delivered and commissioned in Phase-I and for which no additional hardware design is needed. For a given component, the number of boards in Table 5.3 only describes the size needed on the ATLAS experiment. Table 5.4 shows the physical shelf space needs of the Level-0 Trigger system and the power requirements which shall be satisfied for the system installation in USA15; the power estimates are the maximum possible values, which include uncertainties and margins; they are 20% more than the current best estimates.

Common solutions are foreseen, where ATCA blade designs are used in many components of the trigger system. For example, the L0Muon Barrel and Endcap Sector Logic components will use the same hardware module. The same solution is adopted in the Global Trigger system, where a common module is used for the time-multiplexed data distribution, for processing units and for interfacing to the CTP. In other cases this approach is not viable. The NSW and MDT Trigger Processors require different hardware (for example, a mezzanine is foreseen in order to perform segment finding for the MDT Trigger Processor), and the CTP has specific interface needs. The approach of building common blocks was not adopted in the Phase-I system design, since the very tight latency constraints prompted the design of custom processing modules.

Prototypes already exist with a very similar technical complexity with respect to the Phase-II Level-0 components presented in this TDR. The number of Multi-Gigabit Transceivers (MGT) present in Phase-I designs is comparable or superior to the Phase-II system needs, while the bandwidths of individual transceivers will double, up to ≈ 25 Gb/s. The architecture is already well established in terms of interfaces and module interconnectivity, as well the broad use of large FPGAs as core processing elements. The TDAQ Level-0 system is not located in a high-dose rate radiation environment and therefore avoids the challenges of ASIC designs needed elsewhere in ATLAS.
<table><caption>Table 5.3: The size of the Phase-II hardware trigger system. The first column lists the subsystem and the second column lists the hardware component of that subsystem. Different components using the same common module type are indicated in the third column, and the fourth column indicates which modules are commissioned in Phase-I. The fifth, sixth, and seventh columns list the number of ATCA boards, the number of input Multi-Gigabit Transceiver (MGT) links per board, and the number of output MGT links per board, respectively. The LTI output links use PON technology while all other links are point-to-point high speed links.</caption><thead><tr><th>Subsystem</th><th>Component</th><th>Module</th><th>Phase-I deliverable</th><th>Number of Boards</th><th>Input links per board</th><th>Output links per board</th></tr></thead><tbody><tr><td rowspan="4">L0Calo</td><td>eFEX</td><td>-</td><td>Yes</td><td>24</td><td>144</td><td>48</td></tr><tr><td>jFEX</td><td>-</td><td>Yes</td><td>6</td><td>240</td><td>48</td></tr><tr><td>gFEX</td><td>-</td><td>Yes</td><td>1</td><td>312</td><td>108</td></tr><tr><td>fFEX</td><td>-</td><td>-</td><td>2</td><td>240</td><td>48</td></tr><tr><td rowspan="4">L0Muon</td><td>NSW</td><td>-</td><td>-</td><td>16</td><td>148</td><td>28</td></tr><tr><td>Endcap SL</td><td>SL</td><td>-</td><td>48</td><td>96</td><td>60</td></tr><tr><td>Barrel SL</td><td>SL</td><td>-</td><td>32</td><td>60</td><td>60</td></tr><tr><td>MDT</td><td>-</td><td>-</td><td>64</td><td>72</td><td>72</td></tr><tr><td rowspan="3">Global Trigger</td><td>MUX</td><td>GCM</td><td>-</td><td>23</td><td>156</td><td>108</td></tr><tr><td>GEP</td><td>GCM</td><td>-</td><td>24</td><td>108</td><td>36</td></tr><tr><td>CTP Interface</td><td>GCM</td><td>-</td><td>1</td><td>60</td><td>24</td></tr><tr><td>MUCTPI</td><td>-</td><td>-</td><td>Yes</td><td>2</td><td>208</td><td>65</td></tr><tr><td rowspan="4">CTP</td><td>CTPMI</td><td>-</td><td>-</td><td>1</td><td>-</td><td>-</td></tr><tr><td>CTPIN</td><td>-</td><td>-</td><td>1-2</td><td>24</td><td>12</td></tr><tr><td>CTPCORE</td><td>-</td><td>-</td><td>1</td><td>24</td><td>60</td></tr><tr><td>LTI</td><td>-</td><td>-</td><td>36</td><td>1</td><td>8</td></tr></tbody></table>

The biggest challenge of the Level-0 system resides in the initial design stage in understanding of the resource needs for the implementation of the algorithms within a latency budget envelope.

In some cases, like in the L0Muon system, the muon selection algorithms are well established but the processing strategy will change. The current system is distributed between locations in the cavern and in USA15; however, the Phase-II system design dictates an ATCA-based solution that will be completely housed in USA15. The processing done in one $\Delta\eta \times \Delta\phi = 1.0 \times 0.4$ current Level-1 Muon Barrel trigger sector is currently distributed across $\approx 100$ ASICs ($\approx 20 \text{ mm}^2$ area, 180 nm process) and 9 FPGAs (2002 technology). The additional resource needs, required by the new inner RPC layer, will increase this figure. A single FPGA will accommodate the processing equivalent of 150-200 of these ASICs. A preliminary study aimed to establish the processing power of the current biggest FPGAs, has evaluated that with a conservative 50% resource usage, the logic of about 50 ASICs will fit in the largest FPGA available at the time of writing this document, a Xilinx Ultrascale+ device. The challenge in this case is to gain a factor of two by optimising the existing algorithm and another factor of two based on the availability of a new generation of FPGAs.
<table><caption>Table 5.4: A summary of the required rack space in USA15 for each system component. Maximum Possible Values (MPV) of the power needs are also shown, together with the totals for the Level-0 Trigger system.</caption><thead><tr><th>Subsystem</th><th>Component</th><th>Number of Shelves</th><th>MPV Power [kW]</th></tr></thead><tbody><tr><td rowspan="4">L0Calo</td><td>eFEX</td><td>2</td><td>16</td></tr><tr><td>jFEX</td><td>1</td><td>6</td></tr><tr><td>gFEX</td><td>1</td><td>3</td></tr><tr><td>fFEX</td><td></td><td></td></tr><tr><td rowspan="4">L0Muon</td><td>NSW</td><td>2</td><td>9</td></tr><tr><td>Endcap Sector Logic (SL)</td><td>4</td><td>17</td></tr><tr><td>Barrel SL</td><td>3</td><td>12</td></tr><tr><td>MDT</td><td>6</td><td>29</td></tr><tr><td rowspan="2">Global Trigger</td><td>MUX, CTP Interface</td><td>2</td><td>13</td></tr><tr><td>GEP</td><td>2</td><td>16</td></tr><tr><td rowspan="3">Central Trigger</td><td>CTP</td><td>1</td><td>3</td></tr><tr><td>MUCTPI</td><td>1</td><td>3</td></tr><tr><td>LTI</td><td>distributed</td><td>16</td></tr><tr><td colspan="2">Level-0 Trigger System Total</td><td>25</td><td>143</td></tr></tbody></table>

In other cases, like in the Global Trigger system, the resources needed to implement offline-like algorithms is the main technical challenge, while the time-multiplexed architecture has been already proved viable by the CMS experiment.

### 5.2.8 Level-0 Trigger Latency

A bottom-up estimate of the full system latency is an important component in optimising the system architecture. The data coming from all detectors are processed in parallel by L0Calo, L0Muon/MUCTPI and in the initial stage of Global Trigger, executing all algorithms that process full-granularity calorimeter data. The L0Muon system design has the largest latency envelope, since it will perform precise tracking using MDT long-drift-time data, seeded by RPC and TGC muon candidates. A baseline implementation and an option are foreseen in the MDT trigger; to be most conservative the latency quoted is calculated for the option, since it has the longer latency. The estimated latency for the arrival of the muon information from the MUCTPI at the input of Global Trigger is about 4.5 µs.

The latency estimated for the Global Trigger is given in three envelopes. The first two envelopes are related to the calorimeter and muon-only processing which takes the cumulative latencies respectively of ~ 4.4 µs and ~ 5.4 µs. The final step required before taking the final Level-0 decision is the TIP assembly and transmission to CTP via the CTP Interface, which takes the cumulative latency to 5.9 µs.
The overall TDAQ latency budget of 10 µs is defined at the output of the FELIX optical links. Considering the longest possible fibre length at the input of FELIX, the final TDAQ Level-0 latency estimation is 6.9 µs.

Table 5.5 shows a detailed breakdown of the internal processing, link serialisation, deserialisation and multiplexing steps, and signal propagation times along cables and optical fibres for each subsystem. The estimates quoted so far have been calculated as Current Best Estimates (CBE). Starting from Current Best Estimates (CBE) and estimating uncertainties, we introduce the definition of Maximum Possible Values (MPV). All unknown uncertainties contribute at the same level as the known uncertainties, so the MPV values are calculated by summing to CBE known uncertainties twice.

The CBE latency is 6.9 µs, which leads to an MPV latency of 9.1 µs, well within the specified 10 µs limit. Nevertheless every effort must be made to minimise the latency of each component of the system, since the final readout buffers latency will have an additional contribution given by the optical fibres connecting FELIX to the detector front-end electronics; this additional contribution is not part of the TDAQ envelope but needs to be considered in the design of the detector front-ends.

## 5.3 Data Acquisition System

With the increased Level-0 rate and the larger event-size, the data throughput in Run 4 is expected to increase and the DAQ capabilities need to be enhanced accordingly. Moreover, the upgraded DAQ needs to accomplish the requirements coming from the planned changes in the subdetectors, like the new ITk tracker, the modified calorimeter and the new muon-detector readouts, together with other potential new systems. The DAQ system includes Detector Readout subsystem, Dataflow subsystem, the network connection and the common online software framework. Figure 5.4 shows these main functional blocks as part of the Phase-II DAQ system.

### 5.3.1 Readout

The detector Readout subsystem receives event data from detector FE links and facilitates detector-specific processing, such as formatting and monitoring, before final transfer to the dataflow system. It also relays TTC signals and Control and Configuration information to on-detector electronics and relays DCS information between the on-detector electronics and the DCS. It is comprised of the FELIX and the Data Handler.
<table><caption>Table 5.5: Phase-II Level-0 Trigger Latency. Detailed estimations and cumulative values (in µs) are shown for the best estimated values (BEV) and for maximum estimated values (MEV). TP stands for Trigger Processor.</caption><thead><tr><th>Subsystem</th><th>Item</th><th>CBE</th><th>Uncertainty</th><th>∫ CBE</th><th>∫ MPV</th></tr></thead><tbody><tr><td rowspan="4">L0Calo</td><td>LAr signals at FEX inputs</td><td>1.100</td><td>0.15</td><td></td><td></td></tr><tr><td>Tile signals at FEX inputs</td><td>1.425</td><td>0.14</td><td></td><td></td></tr><tr><td>FEX Processing</td><td>0.500</td><td>0.08</td><td></td><td></td></tr><tr><td>FEX to MUX (5 BC + 10m)</td><td>0.175</td><td>0.03</td><td>2.1</td><td>2.6</td></tr><tr><td rowspan="6">L0Muon</td><td>TGC signal at Endcap SL inputs</td><td>0.888</td><td>0.03</td><td></td><td></td></tr><tr><td>RPC signals at Barrel SL inputs</td><td>1.110</td><td>0.03</td><td></td><td></td></tr><tr><td>Barrel SL final pre-processing</td><td>0.390</td><td>0.05</td><td></td><td></td></tr><tr><td>Barrel SL to MDT TP (5 BC + 10m)</td><td>0.175</td><td>0.05</td><td>1.7</td><td>1.9</td></tr><tr><td>NSW signals at SL inputs</td><td>1.425</td><td>0.14</td><td></td><td></td></tr><tr><td>Tile signals at SL inputs</td><td>1.425</td><td>0.14</td><td></td><td></td></tr><tr><td rowspan="4"></td><td>Endcap SL final pre-processing</td><td>0.075</td><td>0.05</td><td></td><td></td></tr><tr><td>Endcap SL to MDT TP (5 BC + 10m)</td><td>0.175</td><td>0.03</td><td>1.7</td><td>2.1</td></tr><tr><td>Last MDT info at USA15</td><td>2.358</td><td>0.10</td><td></td><td></td></tr><tr><td>MDT Trigger (FPGA-based)</td><td>1.277</td><td>0.10</td><td></td><td></td></tr><tr><td rowspan="4"></td><td>MDT Trigger (AM-based)</td><td>1.578</td><td>0.10</td><td></td><td></td></tr><tr><td>MDT TP to SL (5BC + 10m)</td><td>0.175</td><td>0.03</td><td>3.8</td><td>4.3</td></tr><tr><td>SL final processing</td><td>0.025</td><td>0.03</td><td></td><td></td></tr><tr><td>SL to MUCTPI (7BC+10m)</td><td>0.175</td><td>0.03</td><td>4.0</td><td>4.6</td></tr><tr><td rowspan="2">MUCTPI</td><td>MUCTPI processing</td><td>0.250</td><td>0.10</td><td></td><td></td></tr><tr><td>MUCTPI to MUX (5BC + 15m)</td><td>0.200</td><td>0.03</td><td>4.5</td><td>5.3</td></tr><tr><td rowspan="3">Global Trigger Muon</td><td>Muon MUX processing (serdes+fibre)</td><td>0.650</td><td>0.30</td><td></td><td></td></tr><tr><td>Global Trigger pipelined processing</td><td>0.100</td><td>0.05</td><td></td><td></td></tr><tr><td>Global Trigger Muon Triggers</td><td>0.200</td><td>0.03</td><td>5.4</td><td>7.0</td></tr><tr><td rowspan="7">Global Trigger Calo</td><td>LAr signals at MUX inputs</td><td>1.100</td><td>0.15</td><td></td><td></td></tr><tr><td>Tile signals at MUX inputs</td><td>1.425</td><td>0.14</td><td></td><td></td></tr><tr><td>Calo MUX</td><td>1.400</td><td>0.05</td><td></td><td></td></tr><tr><td>Global Trigger pipelined processing</td><td>0.100</td><td>0.05</td><td></td><td></td></tr><tr><td>Global Trigger non-jet triggers</td><td>0.200</td><td>0.03</td><td>3.1</td><td>3.6</td></tr><tr><td>Jet processing (from Global Trigger pipelined</td><td>1.250</td><td>0.50</td><td></td><td></td></tr><tr><td>Global Trigger non-muon triggers</td><td>0.200</td><td>0.03</td><td>4.4</td><td>6.1</td></tr><tr><td rowspan="3">Global Trigger Global</td><td>TIP assembly</td><td>0.050</td><td>0.03</td><td></td><td></td></tr><tr><td>Serial Transmission</td><td>0.250</td><td>0.03</td><td></td><td></td></tr><tr><td>Global to CTP (5BC + 5m)</td><td>0.150</td><td>0.03</td><td>5.9</td><td>7.6</td></tr><tr><td rowspan="4">Central</td><td>CTP Processing</td><td>0.275</td><td>0.10</td><td></td><td></td></tr><tr><td>Link to LTI (5BC + 30 m)</td><td>0.275</td><td>0.03</td><td></td><td></td></tr><tr><td>LTI Internal processing</td><td>0.100</td><td>0.03</td><td></td><td></td></tr><tr><td>Link to FELIX (5BC + 10m)</td><td>0.175</td><td>0.05</td><td>6.7</td><td>8.8</td></tr><tr><td>FELIX</td><td>FELIX Processing</td><td>0.200</td><td>0.05</td><td></td><td></td></tr><tr><td>TDAQ</td><td>From Collision to FELIX out</td><td></td><td></td><td>6.9</td><td>9.1</td></tr></tbody></table>

FELIX FELIX is the component of the Readout subsystem that will implement the interfaces to the detector-specific electronics via custom, point-to-point serial-links, e.g. the Versatile link<fnref n="3" />, and acts as an interface to the Data Handler and DCS via a commodity

<footnote n="3">³ Versatile Link Plus for HL-LHC: https://espace.cern.ch/project-Versatile-Link-Plus/SitePages/Home.aspx</footnote>
<figure><img src="image_58.png" /><figcaption>Figure 5.4: The main functional blocks of the TDAQ architecture for Phase-II, with focus on the DAQ aspects. Shown in green are the Readout components and yellow the Dataflow components, with interfaces to other systems indicated by white for Software dependence, DCS System in blue, Event Filter in Red and Permanent Storage in gray.</figcaption></figure>

multi-gigabit network. TTC information will be received from a PON and relayed to the detector FE electronics as well as to the Data Handler.

The lpGBT protocol is being explored by subdetector systems and L0 trigger system for the bi-directional point-to-point serial links connecting the FELIX and their electronics. These systems will either directly incorporate a GBTX chip on the electronics components or implement lpGBT protocol with FPGAs. For the downlinks (links to the detector electronics), most systems plan to use lpGBT to send TTC information, collect Busy information, and to perform configuration and control. For the uplinks (links from the detector electronics) some systems like ITk foresee to have different protocols to transmit detector data and DCS information. To accommodate the downlink transmission FELIX must also receive packets from the commodity multi-gigabit network and route them to the serial links. This places a requirement on FELIX reliability and uptime beyond that of data taking operations. FELIX therefore functions as a router between custom serial links and commodity multi-gigabit networks. It is largely detector-agnostic and encapsulates common functionality, but minimal detector-specific functionality may be required in FELIX to decode or process the received data beyond what is required to determine its destination.

FELIX is being developed and will be deployed in the Phase-I upgrades of the NSW, LAr calorimeter trigger electronics and the L1Calo and L1Muon. These upgrades only require a subset of the functionality described above and the design and prototyping for Phase-I is
described in the FELIX Phase-I preliminary design review [5.3]. For Phase-II the design of FELIX will be expanded to address the Phase-II specific requirements, namely: new protocol needed; configuration and control of calibration procedures; support of a PON for reception of TTC information and Busy propagation.

Similar to the Phase-I development, FELIX will be implemented with PC server holding custom FPGA I/O cards, which provide lpGBT and other needed protocols as well as the PON interface, the ONU. It is expected that each I/O card will be able to support up to forty-eight bi-directional links and two such mezzanines will be hosted in a commodity-computing server. It is required that the total average input data rate does not exceed 70% of the total input bandwidth availability of the input links of the FELIX card. Based on this model of implementation the size of the Phase-II FELIX system is summarised in Table 5.6. In prototyping for Phase-I the custom card is implemented as a third generation PCIe card. The Phase-II prototype will build on the Phase-I prototyping and evaluate other emerging technologies, such as the fourth generation PCIe.

### Data Handler
The Data Handler receives data from FELIX via a commodity multi-gigabit network. It allows for detector-specific processing, e.g. formatting and/or monitoring, of the data prior to storing them in the Dataflow). To meet the requirements of detector-specific trigger-aware monitoring, automated recovery from error conditions during data taking and fragment book-keeping based on L0A, the Data Handler will also receive the Level-0 trigger information.

The Data Handler infrastructure is expected to operate on commodity PCs and the system size is shown in Table 11.1. The size of the Data Handler system is estimated based on the Phase-I system composition of the FELIX and swROD (1:1), plus additional processing power foreseen for Phase-II detector-specific data processing. Any detector-specific data processing still needed as well as all aspects of configuration, control, and monitoring will be implemented by the customisation of the back-end software services, the raw data processing that is implemented by firmware in the current RODs will be implemented as a customisation of the detector Data Handler.

Since FELIX, the Data Handling infrastructure and the EF farm will all be connected by networks, a change in the current event building paradigm will be possible. In the simplest scenario, FELIX could use a round-robin policy to concentrate data from different Level-0 events into different Data Handling elements. This would provide a first building step in which fragments are composed into larger 'macro' fragments. At the second step, downstream processing would simply join macro fragments into a full event and collect data from a subset of the Data Handling elements for each event. Such a scheme would split the event builder load onto two different systems. However, this may require changes to the detector-specific data-sanity algorithms since not all triggers will be seen by a given Data Handling server. Furthermore, implementing two-step event building may require the synchronisation of the event building steps across the different Readout paths.
<table><caption>Table 5.6: Summary of Phase-II Detector Readout Link and Bandwidth Requirements. Downlink refers to data travelling toward the front-end electronics, and uplink to data travelling from the front-end toward the rest of the DAQ system. Detectors with existing FELIX installations from Phase-I will be updated with new hardware as required.</caption><thead><tr><th>Detector</th><th>Number of FELIX boards</th><th>Number of Links</th><th>Bandwidth (Gb/s)</th></tr></thead><tbody><tr><td>ITk Pixel downlink</td><td rowspan="2">224</td><td>1285</td><td>2.5</td></tr><tr><td>ITk Pixel uplink</td><td>10596</td><td>5</td></tr><tr><td>ITk Strips downlink</td><td rowspan="2">76</td><td>1552</td><td>2.5</td></tr><tr><td>ITk Strips uplink</td><td>1824</td><td>10</td></tr><tr><td>LAr LASP downlink</td><td rowspan="2">36</td><td>100</td><td>2.5</td></tr><tr><td>LAr LASP uplink</td><td>770</td><td>10</td></tr><tr><td>LAr LDPB downlink</td><td rowspan="2">8</td><td>31</td><td>2.5</td></tr><tr><td>LAr LDPB uplink</td><td>155</td><td>10</td></tr><tr><td>L0Calo downlink</td><td rowspan="2">8</td><td>16</td><td>2.5</td></tr><tr><td>L0Calo uplink</td><td>120</td><td>10</td></tr><tr><td>NSW downlink</td><td rowspan="3">96</td><td>864</td><td>5</td></tr><tr><td>NSW uplink</td><td>1440</td><td>5</td></tr><tr><td>NSW Trigger Processor</td><td>64</td><td>5 or 10</td></tr><tr><td>Global Trigger downlinks</td><td rowspan="2">4</td><td>48</td><td>2.5</td></tr><tr><td>Global Trigger uplinks</td><td>96</td><td>10</td></tr><tr><td>Tile</td><td>8</td><td>160</td><td>10</td></tr><tr><td>TGC</td><td>8</td><td>192</td><td>10</td></tr><tr><td>MDT</td><td>64</td><td>1536</td><td>10</td></tr><tr><td>RPC</td><td>4</td><td>64</td><td>10</td></tr><tr><td>CTP</td><td>1</td><td>12</td><td>10</td></tr><tr><td>MUCTPI</td><td>1</td><td>4</td><td>10</td></tr><tr><td>LUCID uplink</td><td>1</td><td>24</td><td>5</td></tr><tr><td>Zero Degree Calorimeters (ZDC) uplink</td><td>1</td><td>24</td><td>5</td></tr><tr><td>AFP uplink</td><td>1</td><td>12</td><td>5</td></tr></tbody></table>
5.3.2 Dataflow

The Dataflow subsystem buffers, transports, aggregates and compresses event data. It is
responsible for the transport of data from the output of the Detector Readout to CERN
permanent storage. The main functional elements of the Dataflow system are the Event
Builder, the Storage Handler, and the Event Aggregator. The Event Builder is the logical
interface to the Readout System. It builds event records and manages the storage volume
of the Storage Handler system. The Storage Handler is a high throughput large volume
storage system which buffers event data before and during processing by the Event Filter.
For events accepted by the Event Filter, the Event Aggregator collects, formats and transfers
the output to CERN permanent storage.

The Dataflow subsystem receives events from the Readout subsystem’s Data Handlers at 1 MHz and buffers them in the Storage Handler at a total writing (i.e. input) throughput of 5.2 TB/s. The Storage Handler provides the Event Filter access to Region of Interest information at 1 MHz and full event access at 400 kHz for a total reading (i.e. output) throughput of about 2.6 TB/s. The Event Aggregator receives the full event record at the output rate of 10 kHz for a total throughput of 60 GB/s out to CERN permanent storage. Figure 5.5 shows a high-level description of the communication between the Dataflow components.

<figure><img src="image_59.png" /><figcaption>Figure 5.5: Logical communications between different components of the Dataflow system.</figcaption></figure>

The Dataflow subsystem will be implemented with commodity servers and storage units.
Compared to Run 1 & Run 2, the plan is to deploy centralised storage buffers large enough
to decouple real-time data taking and EF processing. Additionally, the storage buffer will
provide a new abstraction layer between the Dataflow and the EF: location information of
events or data files on a permanent storage system will be exchanged, offloading the data
movements to the storage layer.

**Event Builder** The role of the Event Builder, as in Run 1 and Run 2, is to physically or logically join the fragments or macro-fragments of an event in a single place. The baseline scheme for Phase-II is to use Regions of Interest (RoI) and Level-0 trigger information to reduce the event rate at Level-0 (1 MHz) to 400 kHz. The events passing this first rejection step are then passed to the Event Filter for further analysis, making use of all data available for each event. Depending on the Storage Handler implementation and characteristics, event building could be physical or logical. In the former case, the event data are indeed gathered in a single storage unit. This can be achieved via a specific computing element, fetching the complete event data before storage, or by a collective effort of multiple elements interacting via a specialised concurrent data format and storage technology. Alternatively, in case of logical event building, the event data are not contiguously stored together. Instead only the metadata information about the fragment locations are collected.

The Event Builder is the logical interface of the Dataflow subsystem to the Readout subsystem and the EF system. The Event Builder will be implemented as a software interface to the Storage Handler. The Data Handlers will write data to the logical storage volume via this interface. Across the Event Builder system events must be tracked at the L0-accept rate of 1 MHz. In the case of an operational issue causing the Storage Handler volume to fill up the Event Builder interface shall throttle Data Handler traffic to reduce the rate of data being written, thus asserting back pressure to the Readout subsystem.

**Storage Handler** The Storage Handler buffers data received from the Readout subsystem to decouple the Readout and Event Filter. The large storage volume needed to achieve the required 7.8 TB/s throughput allows for increased event processing latency. The Readout subsystem accesses the Storage Handler through the Event Builder software layer. The Storage Handler presents the event data to the Event Filter and the Event Aggregator in the form of files within a single name-space implemented with a Distributed FileSystem (DFS).

The storage space can be provided within a performance-tiered cluster using a variety of different media types with different throughput and capacities including: hard-disk drives (HDD), solid-state drives (SSD), non-volatile memory express devices (NVMe) and random-access memory (RAM). While the use of different media types allows the system to meet the high-throughput requirements, the assumption is that to meet the throughput requirement SSD will be the dominant technology for the long-time buffer space during the EF processing. The storage system provides 2.6 TB/s of read access to the Event Filter.
Therefore the long-time buffer storage needs to provide total 7.8 TB/s of reading and writing throughput. The system is sized according to this assumption. Over the past ten years HDD capacity grew by a factor of 10 and the trend is expected to continue through to 2025. The same improvement in capacity can be reasonably expected for SSD technologies, the highest capacity SSD available is ~2 TB currently (thus 20 TB in ten years). Today's SSD technologies provide 2 GB/s of aggregated throughput and this throughput scales with capacity up to the extent that the connectivity can support. With PCIe Gen4 connected SSDs, 5 GB/s can be assumed as an achievable baseline for future SSD throughput. So the throughput needed for the long-time buffer space can be achieved with ~1800 SSDs. Such a system would provide up to 36 PB of total storage capacity and represents over an hour of event buffering before and during Event Filter processing.

The Storage Handler system comprises its own storage units and devices by default but
may also take opportunistic advantage of other systems' storage media to aggregate storage
space where possible and pertinent.

**Event Aggregator** The Event Aggregator integrates a physical storage system on top of which software functionality is implemented. It will take advantage of the Storage Handler and only implement the functionality needed to format and expose the data stored there to the offline infrastructure. It receives events accepted by the Event Filter, performs compression (if needed) and then prepares output files to be transferred to permanent storage. Finally the Event Aggregator will be responsible for any necessary communication with the Tier-0 processing centre if anything beyond data transfer is required.

To meet the requirements of CERN-IT the Event Aggregator provides a buffer area capable
of storing up to 48 hours of accepted event data. This decouples online operation of the data
acquisition system from offline activities and enables the system to cope with disruptions
or malfunctions of the physical connection to the permanent storage outside of the ATLAS
experimental area.

Although Hard Disk Drives (HDDs) could provide the stable storage volume needed HDDs
throughput is not expected to increase considerably in the next decade and throughput
would be a major design constraint. In order to buffer 48 hours of data at 10 kHz with
an event size of 6 MB, it will require the Event Aggregator to have a storage volume of
10 PB. This capacity would require 500 Solid State Disk Drive (SSD)s which are naturally
included as part of the Storage System needed for the Storage Handler. The required output
throughput of 60 GB/s is negligible compared to the total 7.8 TB/s of the Storage Handler. A
common storage system for both the input and output buffer more efficiently use resources
and provides greater system flexibility.
5.3.3 Network

The amount of control traffic during data taking is not expected to grow significantly in
the Phase-II and a dedicated network is not planned for control and monitoring traffic.
Therefore the network upgrade for Phase-II is mainly needed for the Readout network and
the Dataflow network.

**Architecture** The Readout network need high throughput to connect the FELIX and the Data Handlers with additional requirements for DCS, control and monitoring infrastructure interconnection. It will organise the system into slices and connect all the nodes in a given slice to the same high-throughput switch. Each slice will contain a certain number of FELIX and a set of Data Handlers they need to communicate with. All slices will be connected together with a pair of routers on a higher hierarchical level allowing all-to-all communication for DCS, control and monitoring purposes. The Dataflow network provides connectivity between all the Dataflow components and the EF farm. It will aggregate Data Handlers with pizza-box switches and connect the Storage Handler units to the same network switch. A set of Data Handlers will then always write to the same set of Storage Handler units, maximising the throughput and reducing the latency. The switches will have high-throughput uplinks to the network core routers to allow all-to-all communication between the Storage Handler and the rest of the system. For connectivity the EF, EF servers are stored in racks and connected to top-of-rack switches. Every top-of-rack switch will be connected to the core network with enough uplink capacity to ensure the required throughput. For the Event Aggregator to send accepted events to the permanent storage, high-throughput long-range links will be needed between the core routers at Point 1 and the CERN data centre.

**Implementation and Technology** A possible network implementation is illustrated in Fig. 5.6. The router cluster can provide a basic level of network redundancy as needed simply by connecting pairs of uplinks to different devices. Its implementation could have different solutions, a pair of chassis routers or a distributed leaf-spine switch topology. Failures of Data Handlers can be dealt with transparently by re-assigning data to neighbouring handlers.

Such an implementation is suitable for Ethernet technology. There are also several other
network technologies with promising future performance projections in terms of band-
width and latency that can be considered for the Phase-II networks, such as InfiniBand
and OmniPath. R&D work will continue to identify the best suitable technology with tech-
nology tracking, technology evaluation and network slice construction.
<figure><img src="image_60.png" /><figcaption>Figure 5.6: Possible network implementation using Ethernet technology.</figcaption></figure>

### 5.4 Event Filter System

The Event Filter (EF) system takes as input the detector data from events accepted by the preceding hardware trigger at 1 MHz (see 6.11). It must select the most useful events according to the trigger menu at a rate of 10 kHz (see 6.11) and reject the rest. Fast rejection is important to achieve high throughput and minimise Storage Handler space requirements. An initial selection based on combining information from the Level-0 hardware trigger with the regional hardware tracking (rHTT) is used to reduce the event rate down to around 400 kHz, as shown in Table 6.4. This is followed by reconstruction of events using the EF processors to run algorithms that are similar to or in common with the offline reconstruction, and use of global hardware tracking (gHTT) as also shown in Table 6.4.
5.4.1 Use of Tracking in the Event Filter

High luminosity, and consequently high pile-up, conditions give rise to specific challenges
for object and event reconstruction algorithms: higher occupancy of tracking detectors
makes pattern recognition slower and more susceptible to fakes, and energy resolution in
calorimeters is reduced. This negatively affects, for example:

* the distinction between reconstructed particles from a hard scatter and the many su-
  perimposed soft events,

- the separation of electrons from background jets,

- calculation of global event quantities like $E_T^{\text{miss}}$,

• jet energy resolution,

* and separation of b-jets from light jets.

This in turn leads to higher trigger rates and/or worse efficiency. To achieve the goal of
maintaining a menu with thresholds similar to Run 1, the EF selections need to be robust
against pile-up so that rates scale approximately linearly with luminosity. Use of tracking
to identify a primary vertex and associate reconstructed objects with it is a well-established
approach to address this problem.

Efficient charged particle reconstruction in HL-LHC conditions relies on the tracking de-
tector upgrade (ITk) [5.4][5.5] and software improvements. Figure 5.7 shows the CPU usage
per event in units of HEP-SPEC06⁴ (HS06) times seconds for the inclined ITk layout. Even
with the preliminary tuning of the ITk reconstruction software, the total CPU usage spent
on tracking at <μ> = 200 is less than five times that spent on tracking in the Run 2 system
at <μ> = 20. Considering the worse-than-linear expectation for track reconstruction time
using Run 2 software described in Section 3.4.2, a substantial improvement in precision
track reconstruction is expected.

Therefore, the use of information from the Inner Tracker ITk as early as possible in the
trigger selection is considered a key ingredient in the ATLAS Trigger strategy for HL-LHC.
The proposed use of tracking for specific trigger signatures is shown in Table 6.4.

Several technologies may be considered for a reconstructing tracks in the EF:

i a Hardware-based Tracking system for the Trigger (HTT) based on FPGAs and custom-
designed Associative Memory (AM) ASICs,

ii commodity CPU-based servers,

iii systems based on accelerators (e.g. GPGPUs),

iv future architectures based on devices integrating machine learning capabilities.

Some of these options have been studied extensively in the past few years and some are
detailed in Part II of this document.

<footnote n="4">⁴ http://w3.hepix.org/benchmarking.html</footnote>
<figure><img src="image_61.png" /><figcaption>Figure 5.7: The CPU usage required to reconstruct a $t\bar{t}$ event in the ITk as a function of the average pileup, for the inclined ITk layout [5.4]. The total CPU usage required to reconstruct the charged particles in the ITk (filled squares) is compared to the corresponding CPU requirements for reconstructing the current Run 2 detector (open square) at an average pileup of 20 events per bunch crossing. The CPU usage required for the track-finding (circles) and for the ambiguity resolution (triangles) separately are also shown.</figcaption></figure>

The baseline design is an HTT system based on AM ASICs for pattern recognition and FPGAs for track reconstruction and fitting to meet the high trigger rate and throughput requirements at the HL-LHC, as described in Section 5.4.5.

This decision is motivated by the following: extensive experience with the technology within ATLAS, its short latency, its lower power budget and less demanding space requirements, its cost effectiveness and the independence of its cost from the commodity computing market, and the capability to evolve the HTT system for use in the hardware-based Level-1 trigger should ATLAS need to change to a dual L0/Level-1 Trigger (L1)(see Chapter 14). The evolution of the above technologies will be followed, so that the baseline choice may be reconsidered in case of a major technological breakthrough.

Software tracking will still be done in the EF when the ultimate precision is needed, otherwise tracks will be requested from the HTT and simply unpacked and used in EF selections. More advanced software reconstruction techniques for calorimeter and muon detectors will also be needed to achieve performance robust against pile-up and fast enough to run online. In general these will be drawn from or developed with the offline reconstruction, as a high correlation in EF and offline reconstruction efficiencies is desirable.
## 5.4.2 Event Filter System Overview

The EF system will have interfaces with the HTT and Dataflow systems, principally the Storage Handler and Event Builder. Figure 5.8 shows the interactions among these systems. The EF communicates with the HTT via the HTT Interface (HTTIF) which is not shown here but is described in Section 5.4.5.

<figure><img src="image_62.png" /><figcaption>Figure 5.8: Diagram showing the interaction between the Event Filter processing unit (Event Filter Processing Unit (EFPU)), Dataflow system and the hardware tracking (HTT). After receiving the event data from the Dataflow system, the EFPU decides, based on the Level-0 decision, if regional hardware tracking is needed for this event. If so, requests are sent to the relevant HTT units along with the necessary ITk data. After receiving the HTT result the EFPU continues with the event processing including a possible second request for global hardware tracking based on the Level-0 decision or additional EF-based selections.</figcaption></figure>

The EF overall receives events at 1 MHz, with each event assigned to a particular EF processing unit (EFPU). The full event is not read by the EFPU process at this rate. First information only from the L0 CTP and Global Trigger is used to determine the RoIs related to the L0 triggers which passed. The sequences of reconstruction algorithms to run and the choice of whether or not to use the HTT are driven by this information. If regional tracking is required, the EF reads the ITk module data corresponding to the relevant RoIs and sends this to the rHTT. The system is designed for up to 10% of the ITk data to be requested and used in this way, as explained in Section 6.12. If the rHTT was used, the EF then takes a trigger decision based on the regional tracks and Global Trigger objects such as topological calorimeter clusters, to reject some events and reduce the rate to 400 kHz. The dataflow sys-
tem can take advantage of the above partial event data access pattern and transfer the full
event data only for accepted events. If global tracking is required, which will be determined
by the trigger menu, around 10% of events, then the full ITk data is read and sent to the
gHTT. During HTT requests, EF waits the short time (compared to EF event processing)
for the tracks to be returned. Since the EF processing is multi-threaded, other events are
processed during this time so there are no idle CPU cycles. Further software reconstruction
and selection steps will take place until finally at a rate of 10 kHz, events are accepted.

The EF farm and software applications will be controlled by the Online Software system. The software will also provide physics and operational monitoring services. The EF processing is expected to occur promptly, i.e. with a minimum delay after the Level-0 accept decision. The large buffer in the Storage Handler will allow processing timeout settings to be less strict than are needed in the Run 2 and Run 3 system. It is in principle possible for the Storage Handler to buffer the data for longer, to allow processing to continue beyond the end of a data-taking run, thus utilising the inter-fill periods as well. This delayed processing introduces considerable operational complexity that outweighs the benefits unless there is a strong use case. The option of an EF calibration loop (similar to the prompt calibration loop deployed at Tier-0) that would derive certain calibrations before the EF processing starts has been studied. While there is no clear use-case for calorimeter or muons, a full ITk alignment could be derived within one hour of data-taking. However, assuming the new ITk detector is at least as stable as our current detector it is not clear that this would result in significant improvements for the EF selection.

5.4.3 Event Filter Farm Hardware

The most cost-effective computing platform for the EF software, the commodity PC server,
shows a trend towards systems hosting multi-core CPUs with an increasing core-count
and heterogeneous hardware architectures, incorporating General Purpose Graphical Pro-
cessors (GPGPUs) or FPGAs. Therefore, the upgraded EF software should allow for both
parallel algorithm execution as well as exploitation of internal parallelism for those which
are the most costly in CPU terms. The optimal degree of parallelism (multiple events, intra-
event i.e. concurrent Region of Interest (RoI) processing, or intra-algorithm) will be found
by balancing the potential benefits in throughput and the effort needed to modify and main-
tain code.

Current estimates of the evolution of event processing times indicate the need for 4.5<sup>+2.7</sup><sub>-0.7</sub> million HEP-SPEC06<sup>5</sup> (MHS06) to handle a Level-0 rate of 1 MHz, of which an initial reduction to 400 kHz will be achieved entirely by using information from Level-0 and rHTT as shown in Table 6.4. The CPU estimate is based on an extrapolation of current (Run 2) CPU usage, taking into account scaling with pile-up, CPU time reduction due to the use of hardware tracking, and other software improvements. Figure 5.9 shows the expected CPU

<footnote n="5">⁵ http://w3.hepix.org/benchmarking.html</footnote>
<table><caption>Table 5.7: Summary of Event Filter farm size estimates, based on projections of compute capacity requirements and compute power of servers from current data, as described in the text.</caption><tr><td>Compute capacity required</td><td>4.5 MHS06</td></tr><tr><td>Equivalent dual-socket servers</td><td>3000</td></tr><tr><td>Racks</td><td>38</td></tr></table>

requirements versus pile-up assuming most of the ITk tracking is offloaded to HTT as described below in Section 5.4.4. More details on the model used for this estimation are given in Section 12.4. The largest uncertainties in this estimate are due to the expected number of RoIs, the possible improvements in the reconstruction software and the reduction in CPU requirements due to the use of hardware tracks where possible.

<figure><img src="image_63.png" /><figcaption>Figure 5.9: EF CPU extrapolation versus pile-up in million HEP-SPEC06 for the different components of the EF reconstruction software.</figcaption></figure>

All the commodity compute power must be accommodated within a fixed rack-space located in the surface computing infrastructure. This rack-space is shared with other components of the data-acquisition system, such as storage and networking. An extrapolation based on the evolution of compute-power in the ATLAS TDAQ farm over the past ten years results in an estimated compute capacity of 1.5 kHS06 per dual-socket server or approximately 3000 motherboards on the time-scale of Phase-II. The scale of the system is summarised in Table 5.7.

GPGPUs are a potential commodity hardware accelerator to which suitable compute-intensive processing tasks can be offloaded from the main CPU. This has been studied for Phase-I: the findings are summarised in Section 12.3 where further references are provided. In that study it was estimated that using contemporary hardware it would cost approximately
the same, and have similar heating, cooling and space requirements, to increase the farm throughput by adding either GPGPU or CPU. The relative cost-effectiveness of these technologies for the Phase-II EF depends on the relative evolution of CPU and GPGPU in terms of price, performance and packaging.

The decision on the commodity compute hardware for the EF farm will be taken nearer the time of purchase following an evaluation of hardware accelerators. The above work on GPGPUs should be taken as an indication that the software can be successfully adapted to other architectures for a full cost/benefit evaluation.

It is envisaged that the Event Filter farm could be a rather heterogeneous system, possibly containing different classes of hardware such as GPGPU and commodity servers. Due to the rolling replacement strategy, it will host different hardware families within the same class. Since the technology decisions shaping the Event Filter infrastructure will be taken as late as possible, it is important to establish interfaces that will allow for operation in all of the above scenarios.

### 5.4.4 Event Filter Software

The selection software upgrades fall into two parts: further evolution of the framework and development of the selection algorithms to meet Phase-II requirements.

The present software framework is undergoing a major upgrade to provide the new functionality needed for the start of Run 3. The new framework, AthenaMT [5.6][5.7], is being implemented as a common trigger and offline computing framework. Key features are built-in multi-threading support, provision for seamless integration of offline algorithms and infrastructure to support external accelerators. The AthenaMT framework will be able to run existing EF and offline algorithms with limited changes, but additional changes will be needed to fully exploit the potential of the new framework. Most of the changes in the selection software are expected to be done in time for Run 3. Further changes for Run 4 will be needed to adapt the system to the evolved DAQ architecture, i.e. with regards to the Storage Handler and Hardware Tracking interfaces. In addition, new trigger hardware (e.g. Global Trigger) will have to be included into the trigger configuration database. In case GPGPU accelerators will be used the necessary framework services to offload the compute load to these devices will have to be developed.

Significant effort will be required to upgrade the selection software to provide the required rejection in the EF within CPU resource constraints. It is expected that an initial reduction from the Level-0 rate of 1 MHz to 400 kHz can be achieved by the use of hardware tracks and information from Global Trigger. After this initial 'fast' rejection, the remaining required EF rejection power will be achieved by importing techniques currently used offline to provide selections that are robust against the effects of pile-up, and where necessary developing new techniques. Experience from Run 1 and Run 2 has shown that the rates of certain triggers, especially multi-jet triggers and triggers based on $E_T^{\text{miss}}$, rise rapidly with
increasing pile-up. Information on the average number of interactions per bunch-crossing is currently used to reduce the effect of pile-up. However, the most effective methods rely on event-by-event primary vertex reconstruction that provides the number and position of the primary vertices in the event. This allows, for example, the precise calculation of the contribution of pile-up vertices to the energy of a calorimeter cluster.

The biggest change is expected to the inner detector tracking software, as it will have to be adapted to the new ITk detector and make full use of the hardware tracks provided by rHTT and gHTT. Since the trigger tracking software is largely based on the offline tracking software, the additional trigger-specific changes are expected to be of limited scope. Significant experience in the inclusion of hardware tracks is expected to be gained once the FTK system is fully operational in Run 2. The current muon trigger reconstruction [5.8] is composed of a fast muon and inner detector track reconstruction, followed by a combination step and final precision reconstruction in both the inner detector and muon system. The reconstruction software will have to be adapted to include and leverage the information provided by the new MDT Level-0 trigger as well as hardware tracks, both of which should result in a significant reduction in processing time. It is assumed that at least a factor two improvement in the muon reconstruction time can be achieved for Run 4 and this improvement is included in the estimated compute requirements.

The calorimeter software will develop with the aim to further harmonise the trigger and offline reconstruction. With the fast rejection techniques used in the first steps of the HLT moving to the Level-0 trigger, there is both an opportunity to have these without any EF processing, and a consequence that more precision reconstruction will be needed to achieve the necessary rejection. Offline algorithms are the natural option but significant work will be required to speed them up for use at high rates early in the EF. It may be that new algorithms and techniques have to be developed, both for EF and offline reconstruction. The use in the EF of topoclusters produced by the Global Trigger will be studied. In principle they could be used with better object-finding algorithms to do a fast initial rejection in the EF.

### 5.4.5 Hardware-based Tracking for the Trigger Subsystem

The Hardware Track Trigger subsystem (HTT) aims to provide tracks for the EF quickly, hence reducing substantially the processing requirements at the EF. The HTT receives requests to find tracks, along with the related ITk data from the EF. It combines hits from the eight outermost ITk layers (including at least one Pixel layer) to quickly find track candidates. A second stage of processing uses information from all the remaining ITk layers to fit and refine the tracks can be performed when greater precision is required.

Two complementary HTT functionalities are envisaged in the baseline architecture, largely operating on different signatures and with different performance targets. The first is a regional HTT (rHTT) that finds tracks with $p_T > 2$ GeV in limited regions around Level-0
trigger objects that can profit from track information (single high-$p_T$ leptons and multi-object triggers). The rHTT will operate at the full L0A rate of 1 MHz and process on average 10% of the ITk data in these events. The second function, called the global HTT (gHTT), performs full-scan event-level tracking at a nominal rate of 100 kHz. The gHTT finds tracks with $p_T$ > 1 GeV and, in contrast to rHTT, it includes the second stage processing mentioned above, hence providing high-quality tracks with better purity, for EF algorithms that rely more critically on this information (primary/secondary vertices, b-tagging, missing energy).

The input data to the HTT pattern recognition for the full event are ITk module data fragments from a subset of layers, about 2 MB per event. The second stage uses an additional 1.5 MB. For each track candidate, HTT provides the hits associated to it, together with five track parameters ($p_T$, $\eta$, $\phi$, $d_0$, and $z_0$) and the corresponding $\chi^2$ value to assess the quality of the track fit. More sophisticated software algorithms to refit tracks can be used later in the EF, but the CPU-intensive pattern recognition does not have to be repeated.

The first-stage processing of the HTT finds track candidates in two steps: first it finds groups of ITk hits that match precomputed patterns stored in the Associative Memory (AM) ASIC, then processes the matched hit combinations with linearised track-fitting algorithms in FPGAs, to extract the tracking parameters. The capacity of the future Associative Memory 09 ASIC (AM09) chip is expected to be three times larger than the one used in the current FTK project (3 × 128k patterns), with a processing speed of 250 MHz words per input bus. The event processing time is mainly driven by the ITk data transmission through the AM chips and the number of fits to be executed.

The second-stage processing takes as inputs the tracks found in the first stage and the clusters from ITk layers not used in the first stage. It then extrapolates each track to these additional ITk layers, finds clusters that may belong to the track and performs a full track fit that improves the track parameter resolutions significantly. The second-stage processing is implemented in FPGAs.

Being an EF co-processor, the HTT communicates with the EF through a dedicated interface, HTTIF. The HTTIF receives the tracking requests (regional in the case of rHTT) from the EF, together with the ITk data, propagates them to the appropriate Tracking Processor main board in the HTT (TP) boards, receives back the tracking results and returns them to the EF processor that formed the original request. The HTTIF will be implemented with PC servers holding PCIe cards, which communicate with the EF farm via commodity network, and with HTT units via optical links with custom protocol to be defined.

The HTT is organised as an array of independent tracking units called HTT units, as shown in Fig. 5.10. The main hardware building block of the HTT are ATCA boards called Tracking Processors (TPs). There are two types of TP boards: Associative Memory Tracking Processor, AM Trigger Processors (AMTPs), and Second Stage Tracking Processor, Second-Stage Tracking Processors (SSTPs), that will be implemented on identical ATCA boards, with different firmware. Each tracking unit comprises a set of six AMTPs and one SSTP
<figure><img src="image_64.png" /><figcaption>Figure 5.10: Overview diagram of the *HTT* system showing interconnections within *HTT* units and with the *HTTIF*.</figcaption></figure>

<table><caption>Table 5.8: Summary of characteristics and size of the *HTT* system.</caption><thead><tr><th></th><th>HTT</th></tr></thead><tbody><tr><td>rHTT minimum track p<sub>T</sub></td><td>2 GeV</td></tr><tr><td>rHTT Input rate</td><td>1 MHz @ 10%</td></tr><tr><td>gHTT minimum track p<sub>T</sub></td><td>1 GeV</td></tr><tr><td>gHTT Input rate</td><td>100 kHz</td></tr><tr><td>Number of HTTIF</td><td>48 (to be revisited)</td></tr><tr><td>Number of ATCA shelves for AMTPs</td><td>48</td></tr><tr><td>Total number of AMTPs</td><td>576</td></tr><tr><td>Total number of AM chips</td><td>18432</td></tr><tr><td>Number of ATCA shelves for SSTPs</td><td>8</td></tr><tr><td>Total number of SSTPs</td><td>96</td></tr><tr><td>Power estimate per TP</td><td>300 W</td></tr></tbody></table>

that will perform tracking in a specific $\eta - \phi$ region of the track parameter phase space. Table 5.8 gives an overview of the main characteristics and size of the *HTT* hardware.

R&D of the Phase-II AM ASIC based on 28 nm technology is already underway. A first prototype called Associative Memory 07 prototype ASIC (AM07) has been recently re-
ceived and is under test. The next prototype called Associative Memory 08 prototype ASIC (AM08) will be a small area device including all functions of the final AM09 with a smaller number of patterns (16k patterns). The logic and full-custom designed elements of AM08 will be used as a the base for the design of AM09 that will be a large area ASIC to be pro- duced with full-mask submission.

There is confidence that the AM-based baseline design will work. While this is design developed towards the Preliminary Design Review, other technologies such as commodity hardware accelerators are being kept under evaluation in case a major breakthrough occurs which would make it worth changing the design.

References

[5.1] ATLAS Collaboration, Technical Design Report for the Phase-I Upgrade of the ATLAS TDAQ System, Tech. Rep. CERN-LHCC-2013-018. ATLAS-TDR-023, CERN, Geneva, Sep, 2013. https://cds.cern.ch/record/1602235.

[5.2] F. Lanni et al., Interfaces with Detector Front-End Systems. Requirement Document for HL-LHC, Tech. Rep. ATL-DA-ES-0051 v.1, EDMS Id 1563801 v.1, CERN, Geneva, March, 2016. https://edms.cern.ch/document/1563801.

[5.3] P. Farthouat et al., Report of the preliminary design review of the FELIX for Phase 1, Tech. Rep. ATU-TC-ER-0048 v.1, EDMS Id 1518157 v.1, CERN, Geneva, Aug, 2015. https://edms.cern.ch/document/1518157.

[5.4] ATLAS Collaboration, Technical Design Report for the ATLAS Inner Tracker Pixel Detector, Tech. Rep. CERN-LHCC-2017-021, CERN, Geneva, (in preparation).

[5.5] ATLAS Collaboration, Technical Design Report for the ATLAS Inner Tracker Strip Detector, Tech. Rep. CERN-LHCC-2017-005, CERN, Geneva, Apr, 2017. https://cds.cern.ch/record/2257755.

[5.6] J. Baines, T. Bold, P. Calafiura, S. Kama, C. Leggett, D. Malon, G. Stewart, and B. Wynne, ATLAS Future Framework Requirements Group Report, Tech. Rep. ATL-COM-SOFT-2014-048, CERN, Geneva, Dec, 2014. https://cds.cern.ch/record/1974156.

[5.7] J. Baines, T. Bold, D. Oliveira Damazio, S. Martin-Haugh, J. Masik, T. Martin, F. Pastore, H. J. Stelzer, W. Panduro Vazquez, R. White, W. Wiedenmann, F. Winklmeier, B. Wynne, C. Bernius, M. Hodgkinson, C. Leggett, E. Moyse, I. Shapoval, S. Snyder, and G. Stewart, Design of the High Level Trigger in AthenaMT, Tech. Rep. ATL-COM-DAQ-2017-047, CERN, Geneva, Jun, 2017. https://cds.cern.ch/record/2268736.
[5.8] ATLAS Collaboration, Performance of the ATLAS Trigger System in 2015, Eur. Phys. J. C 77 (2017) 317, arXiv:1611.09661 [hep-ex].
<figure><img src="image_65.png" /></figure>
# 6 Expected Performance

The identification of trigger-level objects (such as electrons, muons, and jets) is defined relative to each object's offline definition. The Phase-II TDAQ upgrade will enable the implementation of object identification algorithms that are much closer to the offline definitions than the Run 3 system. The Global Trigger processors deliver trigger objects based on full-granularity calorimeter information at Level-0. The HTT provides tracks to the Event Filter at the Level-0 rate (1 MHz) in regions of interest for tracks above 2 GeV and tracks above 1 GeV at a reduced rate (100 kHz) for the full-detector. In both cases, track reconstruction extends to the full ITk coverage of $|η| < 4.0$. This section describes the expected Phase-II trigger object performance relative to the current (Run 2) understanding of the offline definitions; it is expected that these definitions will continue to evolve beyond this document. In all cases, the performance is evaluated for a luminosity of $\mathcal{L} = 7.5 \times 10^{34} \text{ cm}^{-2}\text{s}^{-1}$.

## 6.1 Performance Estimation Procedures

The Level-0 and early rejection regional tracking in the Event Filter (rHTT) results presented in this section are based on full-simulation studies of the ATLAS detector [6.1] using Geant4 [6.2]. The planned algorithms to be implemented in hardware or software are then applied to the simulation to determine the performance. The trigger efficiencies for the various physics objects are evaluated using samples of signal events (e.g., $Z \to ee$ or $Z \to \tau\tau$) overlaid with an average of $\langle\mu\rangle \simeq 200$ minimum-bias events generated with PYTHIA 8 [6.3]. To reproduce the pile-up conditions expected in Phase-II, background rejections and trigger rates are obtained from a sample of overlapping minimum-bias events with $\langle\mu\rangle \simeq 200$. The metric by which the performance of a given trigger object is evaluated consists of the expected rate on minimum-bias events versus the corresponding effective offline thresholds in signal events. The effective offline threshold is the value of the relevant quantity (such as $p_T$), above which the trigger reaches $\sim 90-95\%$ of its plateau efficiency; the exact efficiency goal depends on the relevant object.

The Event Filter algorithms that are used in data-taking will follow an extensive programme of development of offline reconstruction from now until data-taking and beyond. These developments will increase the sophistication of the algorithms designed to manage the higher level of pile-up and exploit features of the upgraded detector. It is therefore not possible to accurately estimate Event Filter rates with the actual algorithms that will be used. Instead, the Event Filter rates are evaluated using selections based on the current
HLT algorithms applied to Run 2 data linearly extrapolated in luminosity to $\mathcal{L} = 7.5 \times 10^{34} \text{cm}^{-2}\text{s}^{-1}$. For the majority of triggers, the Event Filter rates are approximately linear with luminosity. The exception is the missing transverse energy trigger, for which a dedicated analysis based on the Geant simulation described above is used. The ongoing development of offline reconstruction means the Event Filter must be able to follow those developments to avoid broad turn-on curves and object selection inefficiencies.

## 6.2 Topological Clusters

The proposed Global Trigger will allow the reconstruction of offline-inspired noise-suppressed “topological clusters”, or topoclusters [6.4]. Topoclusters are based on the full-granularity Liquid Argon and Tile calorimeter information for cells with $|E_T| > 2\sigma$, where $E_T$ is the reconstructed cell transverse energy and $\sigma$ is the sum in quadrature of the calorimeter electronics noise and the pile-up noise. In the “422” scheme, each topocluster is seeded from a cell with $|E_T| > 4\sigma$, and neighbouring cells (in three dimensions) with $|E_T| > 2\sigma$ are added to complete the cluster. The full offline topological clustering algorithm [6.4], the “420” scheme, has an additional boundary layer of cells with $E_T > 0$ adjacent to the cluster. In particular, the transverse energy of the reconstructed clusters is not significantly affected by the omission of the $E_T > 0$ boundary layer, although the number of cells in each cluster is substantially smaller. The nominal plan for the upgrade is the implementation of the “422” scheme in the Global Trigger with minor modifications including the use of $E_T$ provided by the calorimeters. The details of the implementation are described in Section 9.3.3. Comparisons of the number of cells per cluster, the number of clusters, and the transverse energy ($E_T$) of the clusters are shown in Fig. 6.1 for $ZH \to vवb\bar{b}$ events. There are on average fewer cells per cluster in the “422” scheme (without the boundary layer). Furthermore, the splitting and merging algorithms are implemented independently, which results in the number of reconstructed clusters being slightly different. The effect of these differences on jets is described in Section 6.6. In addition, calorimeter-based topocluster moments may be calculated and calorimeter-based calibrations may be applied to improve jet and tau performance.

Once formed, the topoclusters will be used as the basis for jet and tau reconstruction. The trigger topocluster objects can also be used to calculate isolation-type variables for electrons, photons, muons, and tau leptons as well as to aid tau identification.

## 6.3 Electrons and Photons

**Level-0** Electron and photon object identification in Phase-II begins in the legacy Phase-I system (using the eFEX). The Global Trigger then refines the identification algorithm by taking advantage of the transmission of fine-granularity cells with $|E_T| > 2\sigma$ from the LAr
<figure><img src="image_66.png" /><figcaption>Figure 6.1: Performance of the proposed “422” (green, labeled “42” in the legend) topocluster reconstruction scheme compared to the offline “420” scheme (red) in ZH → vवbЬ events. The top plots are the number of cells in the clusters and the number of clusters found, and the bottom is the transverse energy of the clusters. The topocluster E_T is calculated with the individual cells calibrated to the electromagnetic scale and no further corrections (“EM Scale”).</figcaption></figure>
<figure><img src="image_67.png" /></figure>

<figure><img src="image_68.png" /><figcaption>Figure 6.2: Performance of the $E_{ratio}$ variable for electron identification assessed on $Z \to ee$ signal and minbias samples. The electron candidate has a selection applied that is similar to the one that will be applied by the eFEX before the candidates reach the Global Trigger with a $p_T$ threshold of 20 GeV.</figcaption></figure>

calorimeter. One promising shower shape variable referred to as $E_{ratio}$ (currently employed in the Run 2 HLT and offline electron and photon identification algorithms [6.5][6.6]) makes use of the first layer of the LAr calorimeter which is not available in the Phase-I eFEX. $E_{ratio}$ is defined as

$$E_{ratio} = \frac{E_{highest \ energy \ cell} - E_{2nd \ local \ maximum \ energy \ cell}}{E_{highest \ energy \ cell} + E_{2nd \ local \ maximum \ energy \ cell}} \quad (6.1)$$

where $E_{highest \ energy \ cell}$ is the energy in the cell with the largest energy deposit associated with the electron and $E_{2nd \ local \ maximum \ energy \ cell}$ is the energy in the next largest local maximum (in a window of typically 0.0625 in $\eta$). This discriminates between dominant background from $\pi^0 \to \gamma\gamma$ showers (whose maximum and second-maximum energy deposits would be balanced) and isolated electrons or photons (whose $E_{ratio}$ is close to 1). Figure 6.2 shows the distribution of $E_{ratio}$ with a $2\sigma$ energy threshold and the efficiency versus rejection when $E_{ratio}$ is only computed for cells whose $|E_T|$ is above the given noise threshold. The latter plot demonstrates that the $|E_T| > 2\sigma$ threshold does not have a significant detrimental impact on the performance of this variable; a factor of five additional rejection can be achieved for ~99% efficiency.

In addition, the availability of topoclusters in the Global Trigger allows for an implementation of the topocluster-based isolation currently used in the offline and HLT reconstruction. The resulting electron trigger rates at $\mathcal{L} = 7.5 \times 10^{34} \text{cm}^{-2}\text{s}^{-1}$ are shown in Figure 6.3a for the eFEX selection only, then plus an $E_{ratio}$ requirement, and finally with an additional topocluster-based isolation requirement. The rate for a 20 GeV threshold with the eFEX selection alone is 600 kHz. The $E_{ratio}$ cut reduces the rate by a factor of $\approx 2 \times$ and then isolation requirement reduces the rate an additional 20-25%, bringing the total rate low
<figure><img src="image_69.png" /><figcaption>(a) Single-electron trigger rates as a function of leading lepton $p_T$</figcaption></figure>

<figure><img src="image_70.png" /><figcaption>(b) Di-electron trigger rates as a function of sub-leading lepton $p_T$</figcaption></figure>

Figure 6.3: The Level-0 rate as a function of leading $p_T$ for the single-electron/photon triggers and sub-leading $p_T$ for dielectron/diphoton triggers. Three levels of selection are shown solely from the eFEX, eFEX plus a requirement on $E_{ratio}$, and after a topocluster-based isolation requirement.

enough such that a 20 GeV threshold takes an acceptable fraction of the total readout bandwidth. The diphoton/dielectron rates are shown in Figure 6.3b.

### Regional Tracking Rejection
In order to support the high Level-0 rate, early rejection in the Event Filter using regional tracking (rHTT) is required. The rejection as a function of efficiency when requiring a track with a minimum $p_T$ is shown in Fig. 6.4. The rejection is approximately a factor of 5 for 95-97% efficiency for an online electron threshold of 18 GeV and a factor of 3 for 95-97% efficiency for an online threshold of 10 GeV.

For dielectron triggers it is also possible to require the candidates be consistent with originating from the same vertex in the z. Study of the rejection expected from that requirement is underway.

### Event Filter Output
Finally in the Event Filter, selections similar to electrons and photons in the offline system are implemented including Gaussian sum filter for the electron tracks to account for radiation along their paths. The rates are summarised in Table 6.1. The single-electron trigger presented in the table has a track-based isolation requirement using tracks above 1 GeV $p_T$ as is used in the current trigger selection.
<figure><img src="image_71.png" /><figcaption>Figure 6.4: Rejection as a function of efficiency when requiring a track for (a) 20 GeV electrons and (b) 10 GeV electrons and muons. The track $p_T$ requirement is indicated as numbers next to the lines. The electron and muon samples are single particle samples with $p_T$ distributions that are flat in $1/p_T$ from 4-400 GeV. The backgrounds are based on minimum bias simulation.</figcaption></figure>

<table><caption>Table 6.1: Projected Event Filter rates for representative electron and photon triggers.</caption><thead><tr><th>Trigger</th><th>Offline Threshold [GeV]</th><th>Rate</th></tr></thead><tbody><tr><td>Level-0 Single Electron</td><td>22</td><td>200 kHz</td></tr><tr><td>After regional tracking cuts</td><td>22</td><td>40 kHz</td></tr><tr><td>Event Filter Isolated Single Electron</td><td>22</td><td>1.5 kHz</td></tr><tr><td>Level-0 Single Photon</td><td>120</td><td>5 kHz</td></tr><tr><td>No regional tracking cuts</td><td>-</td><td>-</td></tr><tr><td>Event Filter Single Photon</td><td>120</td><td>0.3 kHz</td></tr><tr><td>Level-0 Dielectron</td><td>10,10</td><td>60 kHz</td></tr><tr><td>After regional tracking cuts</td><td>10,10</td><td>10 kHz</td></tr><tr><td>Event Filter Dielectron</td><td>10,10</td><td>0.2 kHz</td></tr><tr><td>Level-0 Diphoton</td><td>25,25</td><td>20 kHz</td></tr><tr><td>No regional tracking cuts</td><td>-</td><td>-</td></tr><tr><td>Event Filter Diphoton</td><td>25,25</td><td>0.2 kHz</td></tr></tbody></table>

## 6.4 Muons

**Level-0** The Level-0 trigger for muons, described in Section 8, uses the Phase-I muon trigger RPC, TGC, and NSW detectors with new on-detector and trigger electronics to seed tracking in the high-precision MDT chambers. In addition, new RPC chambers will be added in the barrel region to increase the efficiency which would otherwise be significantly degraded from the Phase-I performance due to a lowering of voltage on the RPC chambers
to avoid aging. Figure 6.5a shows the η − φ coverage for the Phase-I system, which requires
hits in all three RPC layers in order to manage the muon trigger rate. With the new RPCs
this can be relaxed to requiring a coincidence in 3 out of 4 RPC layers. This significantly
increases η − φ coverage as seen in Fig. 6.5b. Finally, with the additional rate rejection from
the MDT system, the RPC requirement can be further relaxed to a two-layer coincidence.
The resulting improvement in η − φ coverage is illustrated in Fig. 6.5c.

The corresponding impact on the maximum efficiency of the 20 GeV muon trigger is shown
in Fig. 6.6a. The line for “3/3 chambers” corresponds to the Phase-I system. The line “3/4
chambers” corresponds to the new RPC configuration (the additional “3/4 chambers with
BO hits” adds a requirement that the outer barrel layer be hit to remove the acceptance
below 10 GeV). The new RPCs chambers increase the efficiency from ~ 80% to ~ 90% on
the plateau. The 2 out of 4 requirement on the RPC layers is restricted to the barrel inner
and barrel outer layers. This is shown in Fig. 6.6a as the “3/4 chambers + BIBO” line, which
achieves an efficiency of ~ 96%.

Also mentioned in Fig. 6.6a is that the RPC trigger rates increase from ~ 20 kHz for the low-efficiency Phase-I system to ~ 85 kHz for the high-efficiency “3/4 chambers + BIBO” scheme. The rate is dominated by the trigger acceptance below threshold, i.e. the trigger accepts a substantial number of muons below the nominal 20 GeV threshold. To reduce the rate due to those muons, the high-precision MDT chambers are used in the muon trigger to significantly sharpen the turn-on curve. The corresponding trigger efficiency turn-on curves for a 20 GeV threshold in the region |η| <2.4 before and after the inclusion of the MDT chamber information are shown in Fig. 6.6b. The MDT selection reduces the “2 out of 4” RPC rate from the ~ 85 kHz to ~30 kHz. It also reduces the end-cap TGC+NSW trigger rate for 20 GeV muons from ~ 30 kHz to ~ 15 kHz.

The dimuons rate estimates are still at an early stage. Each rate has three contributions: two muon candidates from the same collision, two muon candidates from two different collisions, and two muon candidates due to double counting the same muon. We expect to be able to remove the vast majority of the double counting with the muon trigger processor systems. For 10 GeV muons, the different collision contribution is estimated to be a small effect (≈ 1 kHz based on binomial statistics for two independent collisions), and the total rate is estimated based on an overlay procedure to be less than 10 kHz. For 5 GeV muons, the different collision contribution is substantial (approximately 34 kHz) and the total rate will be in the range of 50-150 kHz depending on the details of the topological selection and overlap removal, which are still being optimised. For the 5 GeV dimuon rate and for even lower thresholds topological selections can be used to further reduce the rate for triggers targeting b-physics. In Run 2, such topological triggers give rates a factor of ~ 10 lower. To support b-physics and exotic scenarios within the scope of the proposed hardware, algorithms will be optimised to increase nearby muon acceptance and keep the dimuon thresholds low.
<figure><img src="image_72.png" /><figcaption>(a) $\eta - \phi$ acceptance for the Phase-I system in Phase-II conditions</figcaption></figure>

<figure><img src="image_73.png" /><figcaption>(c) $\eta - \phi$ acceptance for new RPCs operated with a two-station coincidence (any 3 stations or “BIBO”)</figcaption></figure>

<figure><img src="image_74.png" /><figcaption>(b) $\eta - \phi$ acceptance for new RPCs operated with a three-station coincidence</figcaption></figure>

Figure 6.5: $\eta - \phi$ acceptance for 20 GeV $p_T$ trigger for (a) the Phase-I system in Phase-II conditions, (b) for new RPCs operated with a three-station coincidence, and (c) for new RPCs operated with a two or three-station coincidence.

**Regional Tracking Rejection** Using rHTT, the muon trigger can add tracking requirements. For a 20 GeV trigger threshold, this is not necessary as the rate from the Level-0 is low enough to not require addition selections before the full Event Filter selection. For low-$p_T$ muons used in particular in the dimuon topology, a track requirement can reduce the rate with little loss of efficiency. Figure 6.4b shows that a factor of two rejection can be achieved with 99% efficiency. For a dimuon trigger, the rejection would be squared while the efficiency would drop to 98%. In addition, dimuons will be required to be consistent with a common vertex to reduce the impact of pile-up where the two muons are from different collisions.

**Event Filter Output** At the Event Filter, the muons are reconstructed with a method similar to the offline algorithm. Table 6.2 shows a representative set of rates. The single-muon trigger presented has a track-based isolation using a 1 GeV track $p_T$ threshold.
<figure><img src="image_75.png" /><figcaption>Figure 6.6: Efficiency for a 20 GeV $p_T$ muon trigger versus offline muon $p_T$ for (a) the Phase-I system in Phase-II conditions, for new RPCs operated with a three-station coincidence, for new RPCs operated with a two or three-station coincidence (see text for details of the configurations), and (b) for RPCs operated with a two or three-station coincidence and a MDT-based requirement.</figcaption></figure>

<table><caption>Table 6.2: Event Filter rates for representative triggers</caption><thead><tr><th>Trigger</th><th>Offline Threshold [GeV]</th><th>Rate</th></tr></thead><tbody><tr><td>Level-0 Single Muon</td><td>20</td><td>45 kHz</td></tr><tr><td>No regional tracking cuts</td><td>-</td><td>-</td></tr><tr><td>Event Filter Isolated Single Muon</td><td>20</td><td>1.5 kHz</td></tr><tr><td>Level-0 Dimuon</td><td>10,10</td><td>&lt;10 kHz</td></tr><tr><td>After regional tracking cuts</td><td>10,10</td><td>&lt;5 kHz</td></tr><tr><td>Event Filter Dimuon</td><td>10,10</td><td>0.2 kHz</td></tr><tr><td>Level-0 Low-$p_T$ Dimuon</td><td>5,5</td><td>50-150 kHz</td></tr><tr><td>no topological cuts</td><td></td><td></td></tr><tr><td>Level-0 Low-$p_T$ Dimuon</td><td>5,5</td><td>&lt; 15 kHz</td></tr><tr><td>with topological cuts</td><td></td><td></td></tr><tr><td>Low-$p_T$ after regional tracking cuts</td><td>5,5</td><td>up to 10 kHz</td></tr><tr><td>Event Filter Low-$p_T$ Dimuon</td><td>5,5</td><td>up to 0.5 kHz</td></tr></tbody></table>
<figure><img src="image_76.png" /><figcaption>Figure 6.7: Rate as a function of leading and sub-leading online (uncalibrated) $\tau~p_T$ for a di-$\tau$ trigger implemented in the eFEX and the corresponding efficiency per tau candidate (referred to as an “RoI” in the plot) with respect to offline for a set of online $\tau~p_T$ thresholds as a function of the offline $\tau~p_T$.</figcaption></figure>

## 6.5 Tau Leptons

**Level-0** The Level-0 tau lepton trigger can use the eFEX to define the initial candidate region and then makes use of the fine granularity calorimeter data reconstructed with the topocluster capability of the Global Trigger. The offline tau selection uses tracking and calorimeter information combined using a Boosted Decision Tree (BDT). Two preliminary strategies are under development for tau identification. The cut-based trigger uses the medium granularity super-cell variables that are available in the eFEX. The second uses a recurrent neural network to select tau candidates in the Global Trigger. At the current early level of optimisation, both give comparable results, but it is expected that with further development a combined system can give better performance with moderate resource usage in the Global Trigger. Both algorithms approximately support a physics goal of reaching $\approx 80-90\%$ of the efficiency plateau for offline $p_T$ for leading $\tau~p_T > 40$ GeV and a sub-leading $\tau~p_T > 30$ GeV, which is motivated by the key $H \to \tau\tau$ and $HH \to b\bar{b}\tau\tau$ analyses. This goal is not yet met by a small factor by either algorithm, but they are expected with further development.

The cut-based results use the energy in a narrow core, information on the depth profile of the energy deposition, and isolation requirements. The resulting rates and efficiencies are shown in Fig. 6.7. A 200 kHz rate corresponds to online $\tau$ thresholds of $p_T > 20$ GeV and $p_T > 15$ GeV for the leading and subleading $\tau$ candidates, respectively. These thresholds correspond to $\approx 85\%$ efficiency for offline $\tau$ candidates with $p_T$ thresholds of 45 GeV and 35 GeV for the leading and subleading $\tau$ candidates, respectively.

The recurrent neural network combines the information from up to six topoclusters. For each cluster, the input variables are cluster energy, the energy in the four layers of the electromagnetic calorimeter, the $\Delta R$ distance from the seed jet axis, three moments of the
<figure><img src="image_77.png" /><figcaption>Figure 6.8: Rate as a function of leading and sub-leading online (uncalibrated) $\tau\ p_T$ for a di-$\tau$ trigger implemented in the Global Trigger using an recursive neural-network (left) and the corresponding efficiency per tau candidate with respect to offline for a set of online $\tau\ p_T$ thresholds as a function of the offline $\tau\ p_T$ (right).</figcaption></figure>

cluster shape, the depth of the cluster in the calorimeter, the fraction of energy contained in the highest energy cell, and the probability that the cluster is an electromagnetic shower based on energy distribution in the cluster. Figure 6.8 shows preliminary results for the di-$\tau$ rates as a function of the leading and sub-leading $\tau\ E_T$ and the corresponding efficiencies for a range of online $\tau\ E_T$ thresholds that correspond to a 200 kHz trigger rate. Such a selection reaches ≈ 85% efficiency for offline $\tau$ candidate thresholds of $p_T > 45$ GeV and $p_T > 45$ GeV for leading and subleading $\tau$ candidates, respectively.

**Regional Tracking Rejection** Regional tracking can be used to further reduce the background rate early in the Event Filter processing. Figure 6.9a shows the rejection versus efficiency for requiring one to five tracks in a cone of $\Delta R < 0.2$ around the candidate tau as function of the track $p_T$ requirement. A modified version of this requirement, also shown, only raises the $p_T$ requirement of the leading track while keeping requirement on additional tracks at $p_T > 2$ GeV and requiring that those tracks are consistent with coming from the same vertex in $z$; this algorithm gives better performance. For di-$\tau$ triggers, two $\tau$ candidates can additionally be required to be consistent with coming from the same vertex using a $\Delta z_0$ cut. This is shown in Fig. 6.9b. The rate can be reduced by a factor of approximately 3.5 with an efficiency loss of ≈ 4%.

**Event Filter Output** After the regional tracking rejection, the Event Filter adds tracking down to 1 GeV for $\tau$ candidates using gHTT. The tracks are used in the BDT and for track-based isolation. Table 6.3 shows rates after the Event Filter selection. The rate of an inclusive isolated di-$\tau$ trigger is too large to record from the Event Filter. Additional requirements such as a $\Delta R < 3$ selection on the $\tau$ candidates to veto back-to-back dijets, additional jet and b-jet requirements, and $E_T^{\text{miss}}$ requirements will likely be part of the menu. These additional
<figure><img src="image_78.png" /></figure>

(a) The rejection versus efficiency for tau candidates as a function of the track $p_T$ (small text next to the points) requirement for various Level-0 selections. Candidates are required to have one to five tracks. The dark blue curve maintains a 2 GeV requirement on the subleading tracks and requires them to be consistent with the $z_0$ of the leading track.

<figure><img src="image_79.png" /></figure>

(b) The rejection versus efficiency for di-tau candidates as a function of the tracking requirement. All three lines have the same Level-0 requirement of $p_T > 20$ GeV on the leading $\tau$ candidate and $p_T > 12$ GeV on the sub-leading $\tau$ candidate. The green line requires just one to five tracks above the track $p_T$ shown in the text next to the points. Light blue line then requires the leading $p_T$ track in each candidates to be consistent with the same vertex (suppressing pile-up). Finally the dark blue line allows the loosens the $p_T$ requirement on the subleading tracks to 2 GeV and requires them to be consistent with the leading track $z_0$.

Figure 6.9: Tau performance using regional tracking (rHTT) in the EventFilter. The efficiencies indicated for the cut-based eFEX Level-0 algorithm with additional tracking requirements. The right most point on each curve is the Level-0 efficiency with no tracking requirements.

requirements will place significant demands on the Event Filter tracking after the regional-tracking-based cuts.

<table><caption>Table 6.3: Event Filter rates for representative $\tau$ triggers</caption><thead><tr><th>Trigger</th><th>Offline Threshold [GeV]</th><th>Rate</th></tr></thead><tbody><tr><td>Level-0 Single Tau</td><td>150</td><td>3 kHz</td></tr><tr><td>No regional tracking cuts</td><td>-</td><td>-</td></tr><tr><td>Event Filter Isolated Single Tau</td><td>150</td><td>0.35 kHz</td></tr><tr><td>Level-0 Di-τ</td><td>40,30</td><td>200 kHz</td></tr><tr><td>After regional tracking cuts</td><td>40,30</td><td>40 kHz</td></tr><tr><td>Event Filter Isolated Di-τ</td><td>40,30</td><td>1.6 kHz</td></tr><tr><td>Event Filter Isolated Di-τ with 0.3 &lt; ΔR &lt; 3</td><td>40,30</td><td>0.5 kHz</td></tr></tbody></table>
## 6.6 Jets

**Level-0** In addition to using offline-inspired topoclusters as inputs, a second important goal of the Global Trigger is the implementation of an offline-like jet-finding algorithm similar to the anti-$k_t$ algorithm. The anti-$k_t$ algorithm [6.7] used offline iteratively builds jets by merging nearby clusters starting with the highest-$p_T$ clusters until a maximum separation set by the parameter $R$ is reached. The standard jets used offline in ATLAS are $R = 0.4$ jets, though $R = 1.0$ jets, referred to as large-$R$ jets, are used in special cases as discussed in Section 6.8.

Figures 6.11b and 6.11d show that in multi-jet events the jFEX sliding window algorithm has a significant inefficiency for near-by offline jets, which leads the trigger turn-on to not reach full efficiency even at high offline jet $p_T$.

Figures 6.10 and 6.11 show the rate versus effective offline threshold and trigger efficiencies for single, three, and four jet triggers for the jFEX algorithm and anti-$k_t$ with jFEX towers, gFEX towers, and 422 topoclusters (which are described in Section 6.2). The effective offline threshold is defined to be the point where the trigger is at 95% of its plateau efficiency (maximum efficiency at high offline jet $p_T$). For each trigger, the efficiencies are shown for an online threshold corresponding to that same rate, so that the 95% efficiency points can be compared. Also shown is the trigger efficiency for anti-$k_t$ clustering for either jFEX or gFEX towers. The anti-$k_t$-based algorithms reach full efficiency at high offline jet $p_T$. In addition to improving the performance of close-by jets, the anti-$k_t$ 422 topocluster algorithm reaches 95% efficiency about 10 GeV earlier for three and four-jet triggers than the tower-based algorithms. The results shown may be moderately improved through more detailed calibration of the 422 jets.

In order to make the anti-$k_t$ processing feasible in the Global Trigger, it may be necessary to reduce the number of inputs to the iterative anti-$k_t$ algorithm. An example possibility is to bin the topoclusters in $\eta$ and $\phi$ to a coarser geometry. This reduces the number of constituents that the iterative algorithm needs to handle without significant impact on the jet performance. Figure 6.12, shows the difference between the resulting jets due to the different thresholds and split/merge algorithms used for reconstructing the topoclusters, and due to binning the clusters before the anti-$k_t$ jet building. For both minbias and a $Z' \to t\bar{t}$ signal, the binning versus not-binning makes a small difference in the number of reconstructed jets, while the change in the threshold (422 vs 420) makes a moderate difference. Similarly the variations make only a small difference in the minbias jet $p_T$ distribution. Finally, the mass of the signal jets is unaffected by the binning and only slightly affected by the threshold difference.

**Regional Tracking Rejection** For multi-jet triggers, the regional tracking can be used to suppress the rate of events where the jets come from different interactions. Jets are required to be consistent with coming from a common vertex using tracks above 2 GeV associated to
<figure><img src="image_80.png" /><figcaption>Figure 6.10: Level-0 trigger rates versus threshold and event-level trigger efficiencies for single-jet triggers. The jFEX algorithm (grey) and anti-$k_t$ with jFEX towers (green), gFEX towers (blue), and 422 topoclusters (red) are compared.</figcaption></figure>

the jets within a cone of $\Delta R < 0.4$. The vertex is constructed from all jets above the jet $p_T$ threshold. A ratio $R_{pT}$ is then constructed as the fraction of the sum of the track $p_T$ associated to the jet and consistent with the primary vertex with respect to the total calorimeter-based measurement of the jet $p_T$. Jets associated with the primary vertex will have larger $R_{pT}$ than jets from other vertices. Scanning over $R_{pT}$ requirements, Fig. 6.13 shows the rejection of jets from other vertices ("pile-up jets") as a function of the efficiency for jets from the primary vertex ("hard-scatter jets"). The efficiency for 20-40 GeV jets (Fig. 6.13a) reaches a maximum of ~90% using 2 GeV tracks and 97% using 1 GeV tracks, because some 20-40 GeV jets have no tracks above 2 GeV. Similarly, the efficiency for the 40 GeV jets (Fig. 6.13b) reaches a maximum of ~90% using 4 GeV tracks and ~95% using 2 GeV tracks. The resulting rate versus threshold for a four-jet trigger after requiring a common vertex using $R_{pT}$ is shown in Fig. 6.14. The efficiency loss from the requirement is 1-2% for the $HH \to 4b$ events passing a Level-0 with the same jet thresholds.

To estimate the needed hardware tracking for multi-jet triggers, Fig. 6.15 shows the average number of jets in an event as function of the minimum jet $p_T$ for events that are selected at Level-0 to have at least four jets with an effective offline $p_T$ threshold of 55 GeV or 65 GeV. For jets with offline $p_T > 50$ GeV approximately 5 jets are present per event. This is relevant for the regional tracking needed to confirm a common z vertex.
<figure><img src="image_81.png" /><figcaption>(a) Three-jet trigger rates vs effective offline threshold for the 3<sup>rd</sup> highest p<sub>T</sub> jet.</figcaption></figure>

<figure><img src="image_82.png" /><figcaption>(b) Three-jet trigger efficiency versus the 3<sup>rd</sup> highest offline jet p<sub>T</sub> for triggers with a rate of 50 kHz.</figcaption></figure>

<figure><img src="image_83.png" /><figcaption>(c) Four-jet trigger rates vs effective offline threshold for the 4<sup>th</sup> highest p<sub>T</sub> jet.</figcaption></figure>

<figure><img src="image_84.png" /><figcaption>(d) Four-jet efficiency versus the 4<sup>th</sup> highest offline jet p<sub>T</sub> for triggers with a rate of 50 kHz.</figcaption></figure>

Figure 6.11: Level-0 trigger rates versus threshold and event-level trigger efficiencies for three-jet and four-jet triggers. The jFEX algorithm (grey) and anti-$k_t$ with jFEX towers (green), gFEX towers (blue), and 422 topoclusters (red) are compared.
<figure><img src="image_85.png" /><figcaption>(a) $p_T$ distribution of jets reconstructed in minimum bias simulation</figcaption></figure>

<figure><img src="image_86.png" /><figcaption>(b) Number of $R = 0.4$ jets reconstructed in minimum bias simulation</figcaption></figure>

<figure><img src="image_87.png" /><figcaption>(c) Number of $R = 1.0$ jets reconstructed in $Z' \to t\bar{t}$ simulation</figcaption></figure>

<figure><img src="image_88.png" /><figcaption>(d) Jet mass reconstructed in $Z' \to t\bar{t}$ simulation</figcaption></figure>

Figure 6.12: Comparisons of topocluster-building thresholds and binning on distributions related to jet reconstruction at Level-0.
<figure><img src="image_89.png" /><figcaption>(a) 20-40 GeV $p_T$ jets comparing 1 GeV and 2 GeV track $p_T$ requirements</figcaption></figure>

<figure><img src="image_90.png" /><figcaption>(b) $p_T$ > 40 GeV jets comparing 2 GeV and 4 GeV track $p_T$ requirements</figcaption></figure>

Figure 6.13: The rejection of jets from other vertices (“pile-up jets”) as a function of the efficiency for jets from the primary vertex (“hard-scatter jets”) as a scan over the $R_{pT}$ requirement.

<figure><img src="image_91.png" /></figure>

Figure 6.14: Rate for a four-jet trigger requiring the jets to be consistent with a common vertex using rHTT. The rate is shown as a function of the effective offline threshold for the lowest (“4th”) $p_T$ jet. The red points show the rate before the tracking requirements. The rate after tracking is shown using 1 GeV (green squares), 2 GeV (yellow upward pointing triangles), 4 GeV (dark blue downward pointing triangles), and 8 GeV (light blue diamonds). For this study, jets using the offline calorimeter only jets using “420” are used, but the tracking rejection is not expected to be correlated with this difference.
<figure><img src="image_92.png" /><figcaption>Figure 6.15: The mean number of jets in events as a function of the minimum jet $p_T$ for events that are selected at Level-0 to have at least 4 jets with $p_T$ above 50 GeV for two threshold scenarios. The error bars on the plot indicate the RMS of the jet distributions. The x-axis jet energy is the calibrated offline energy.</figcaption></figure>

**Event Filter Output** The Event Filter then uses the full calorimeter data including cells below the $2\sigma$ noise threshold to reconstruct jets with the same configuration as offline. Even with full offline jet reconstruction, the rate of four-jet events will be too high to reach the threshold needed for key physics goals such as $HH \rightarrow 4b$. An acceptable Event Filter output rate would require a ~ 100 GeV threshold. To reduce this rate and preserve the main physics goals and opportunities, a set of additional selections will be applied in the Event Filter. These include b-tagging and additional jets and $E_T^{miss}$ requirements. To allow the Event Filter requirements to be comparable to what is possible offline the target jet $p_T$ threshold is 20-25 GeV. Figure 6.15 shows that for jets with $p_T > 20$ GeV, an average of 13 jets per event passes the Level-0 trigger selection. These would cover a substantial fraction of the detector leading to the need for the full-detector tracking provided by the gHTT system. Furthermore, Fig. 6.13 shows that for this range of jet $p_T$, a 1 GeV track $p_T$ threshold is needed to apply vertex constraints with high efficiency. These tracks are also key to enabling b-tagging and the offline track-based calibration to be used.

Offline jet reconstruction will continue to evolve prior to data-taking. It will likely use an increasing amount of tracking information as in the particle flow algorithm [6.8][6.9]. A key feature of the hardware-based track reconstruction is that it will allow the trigger to follow that evolution to maintain good turn-on curves. Figure 6.16 shows how the current implementation of particle flow on ATLAS depends on the $p_T$ above which tracks are available. There is only a slight degradation between the current offline minimum $p_T$ (0.5 GeV) and 1 GeV. By 2 GeV, the performance is significantly degraded.
<figure><img src="image_93.png" /><figcaption>Figure 6.16: The dependence of the jet $E_T$ resolution for particle flow jets in Run 2 on the input tracking $p_T$ threshold.</figcaption></figure>

## 6.7 Missing Transverse Energy

Missing transverse energy ($E_T^{\text{miss}}$) reconstruction is a significant challenge at high pile-up for both the trigger and the offline reconstruction. The current offline makes a sum of all reconstructed objects using careful overlap removal to avoid double counting of energy. The $E_T^{\text{miss}}$ is calculated as the magnitude of $p_T^{\text{miss}}$, which is defined according to the 2-D vector sum

$$ \mathbf{p}_{\mathrm{T}}^{\mathrm{miss}} = - \sum_{\substack{\text{electrons} \\ \text{photons}}} \mathbf{p}_{\mathrm{T}}^{\mathrm{e}} - \sum_{\substack{\text{muons} \\ \text{jets}}} \mathbf{p}_{\mathrm{T}}^{\gamma} - \sum_{\substack{\text{taus} \\ \text{muons}}} \mathbf{p}_{\mathrm{T}}^{\mu} - \sum_{\substack{\text{tau} \\ \text{jet}}} \mathbf{p}_{\mathrm{T}}^{\tau} - \underbrace{\sum_{\substack{\text{jets} \\ H_T^{\text{miss}}}} \mathbf{p}_{\mathrm{T}}^{\text{jet}}}_{\text{soft term}} - \underbrace{\sum_{\substack{\text{tracks} \\ \text{tau} \\ \text{jet}}} \mathbf{p}_{\mathrm{T}}^{\text{track}}}_{\text{soft term}}. \quad (6.2) $$

The final term, referred to as the “soft” term, involves a sum over all tracks in the full detector coverage. All objects, including the tracks in the soft term, are constrained to be consistent with originating from the primary vertex. The trigger performance described in this section is measured relative to a representative offline $E_T^{\text{miss}}$ defined as the sum in Equation 6.2, including only jets with $p_T > 20$ GeV and a soft term, both of which use 1 GeV $p_T$ tracks for vertex constraints. In general, the $E_T^{\text{miss}}$ trigger is only used for signatures that are primarily hadronic (jets and soft term) and where the contributions from the other terms are small.
**Level-0** At Level-0, there are several calorimeter-only $E_T^{\text{miss}}$ options under development. This section will focus on a trigger based on the calorimeter-only jets described in the previous section. This variable is referred to as $H_T^{\text{miss}}$ in analogy to the standard $H_T$ variable which is just the scalar sum of the jet $p_T$. Here the $H_T^{\text{miss}}$ is the magnitude of the vector sum of the transverse components of the jets. Also under study is a similar variable which also includes a calorimeter-based soft-term using topoclusters. In addition, because the Global Trigger has the full event available to an FPGA algorithm, a wide variety of pile-up mitigation strategies are possible and are under investigation.

**Regional Tracking Rejection** Regional tracking is used to require that the jets in the $E_T^{\text{miss}}$ calculation are consistent with a common primary vertex. Figures 6.17a and 6.17b show the Level-0 rate and the rate after regional tracking as a function of the offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient, for a range of minimum $p_T$ and maximum $|\eta|$ of the tracks used in the vertex constraint, respectively. The $H_T^{\text{miss}}$ here is reconstructed with a 50 GeV threshold on the constituent jets, which is expected to be sufficiently high to suppress contributions from pile-up.

The Level-0 rate shows that the Phase-II upgrade supports a $E_T^{\text{miss}}$ trigger that is efficient for offline missing energy at ~210 GeV with a rate of 80 kHz. For the baseline configuration (tracks with $p_T$ above 2 GeV and $|\eta| < 4.0$) regional tracking reduces this rate to 4 kHz for the same threshold. While the 8 GeV minimum track $p_T$ significantly degrades the results, the performance is not strongly sensitive to the $p_T$ cut below 4 GeV. Reducing the $\eta$ coverage from $|\eta| < 4.0$ to $|\eta| < 3.2$ does not have a strong impact, while reducing to $|\eta| < 2.5$ raises the rate at a 210 GeV threshold from 4 kHz to 6 kHz.

Figures 6.17c and 6.17d show the efficiency versus the true $E_T^{\text{miss}}$ from invisible particles and the representative offline $E_T^{\text{miss}}$. The performance versus the representative offline $E_T^{\text{miss}}$ is most relevant for analysis, while the performance versus the true $E_T^{\text{miss}}$ demonstrates that this performance is due to a correlation similar correlation with the true $E_T^{\text{miss}}$ and not specific to the representative offline $E_T^{\text{miss}}$ chosen. These figures also show that the effect of the tracking requirement is mainly to remove events with low true $E_T^{\text{miss}}$ and offline $E_T^{\text{miss}}$.

The rHTT will provide tracking on up to 10% of the ITk data averaging over all events. To estimate the tracking required to implement the $E_T^{\text{miss}}$ trigger, Figure 6.18 shows the mean number of jets per event for which tracking would be needed as a function of the jet $p_T$. For a 50 GeV jet, this is 2.8 jets on average corresponding to 13-14% of the ITk data. When this is combined with the full set of Phase-II triggers, this is within the capability of the system.

**Event Filter Output** Like the jet reconstruction, $E_T^{\text{miss}}$ in the Event Filter makes use of the full calorimeter data including cells below the $2\sigma$ noise threshold and tracking above 1 GeV. For the Event Filter, the $E_T^{\text{miss}}$ reconstruction will follow as closely as possible the offline development which is expected to evolve in sophistication before the turn-on of the
<figure><img src="image_94.png" /></figure>

(a) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various minimum track $p_T$ requirements used in the vertex matching. The full $|\eta| < 4.0$ tracker coverage is used.

<figure><img src="image_95.png" /></figure>

(c) Efficiency as a function of true $E_T^{\text{miss}}$ for the Level-0 and after a regional tracking requirement with $|\eta| < 4.0$ and a minimum track $p_T$ of 2 GeV.

<figure><img src="image_96.png" /></figure>

(b) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various track $\eta$ coverage assumption used in the vertex matching. A minimum track $p_T$ of 2 GeV is assumed.

<figure><img src="image_97.png" /></figure>

(d) Efficiency as a function of offline $E_T^{\text{miss}}$ for the Level-0 and after a regional tracking requirement with $|\eta| < 4.0$ and a minimum track $p_T$ of 2 GeV.

Figure 6.17: Performance of the calorimeter-based $E_T^{\text{miss}}$ trigger at Level-0 based on the $H_T^{\text{miss}}$ variable (50 GeV jets) and the same variable after regional tracking requirements that the jets used are consistent with a common vertex.
<figure><img src="image_98.png" /><figcaption>Figure 6.18: The mean number of jets for events selected by a Level-0 $E_T^{\text{miss}}$ trigger for two threshold scenarios (L0 MHT in legend). The error bars on the plot indicate the RMS of the jet distributions. The x-axis jet energy is the calibrated offline energy.</figcaption></figure>

HL-LHC. It is therefore important that the system be able to support a range of algorithms including the use of tracking.

In order to quantify the impact of the trigger system capabilities on the ability to reproduce the offline $E_T^{\text{miss}}$, a representative $E_T^{\text{miss}}$ calculation similar to the current offline, previously described, is explored for its dependence of the minimum tracking $p_T$ and $\eta$ coverage. Figures 6.19a and 6.19b show the dependence of performance of this definition of $E_T^{\text{miss}}$ on the minimum $p_T$ and the $\eta$ coverage of the tracking, respectively. It is assumed that 20 GeV jets will be used for the jet term. The 1 GeV minimum $p_T$ scenario marginally outperforms the 2 GeV scenario and the 4 GeV has approximately 30% more rate for the same threshold. Similarly, reducing the $\eta$ coverage from $|\eta| < 4.0$ to $|\eta| < 3.2$ has a small impact while reducing to $|\eta| < 2.5$ raises the rate by ≈ 40%. It should also be noted that the impact of the $\eta$ coverage is model dependent. In Run 2, it was seen that the optimisation that improved the performance from $ZH \to \nu\bar{\nu}$ degraded the performance for VBF $H \to$ invisible, which is likely to be the case with reduced $\eta$ coverage.

In order to perform the full $E_T^{\text{miss}}$ calculation in Eqn. 6.2, full-detector tracking is needed to calculate the soft term. Figures 6.20a and 6.20b show the rates for the $H_T^{\text{miss}}$ variable which does not include the soft-term. The rates are ≈ 20% larger and the degradation for reductions in $p_T$ and $\eta$ coverage are similar to the $E_T^{\text{miss}}$ variable at a 210 GeV threshold. For lower thresholds, the degradation from removing the soft-term is larger (≈ 50%). The low $E_T^{\text{miss}}$ region will be important when a $E_T^{\text{miss}}$ requirement is used in combination with other requirements, e.g. in di-$\tau$ or multi-jet Level-0 triggers.
<figure><img src="image_99.png" /><figcaption>(a) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various minimum track $p_T$ requirements used in the vertex matching. The full $|\eta| < 4.0$ tracker coverage is used.</figcaption></figure>

<figure><img src="image_100.png" /><figcaption>(b) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various track $\eta$ coverage assumptions used in the vertex matching. A minimum track $p_T$ of 1 GeV is assumed.</figcaption></figure>

Figure 6.19: Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for a $E_T^{\text{miss}}$ trigger based on the $E_T^{\text{miss}}$ variable (20 GeV jets) which includes a track-based soft-term in the Event Filter using gHTT.

Finally, Fig. 6.21a illustrates the impact of soft-term on the efficiency as a function of true $E_T^{\text{miss}}$. However since analyses use the offline $E_T^{\text{miss}}$, Figure 6.21b shows the efficiency as a function of offline $E_T^{\text{miss}}$ for $H_T^{\text{miss}}$ and $E_T^{\text{miss}}$ with a minimum track $p_T$ to 2 GeV. By definition, the efficiency as a function of offline $E_T^{\text{miss}}$ for the $E_T^{\text{miss}}$ variable with a 1 GeV minimum track $p_T$ is a step function at 200 GeV, so the shape of these curves shows the effect of raising the minimum track $p_T$ to 2 GeV.

If the soft-term is excluded, a large area of the detector is still needed for tracking in order to support the 20 GeV jet threshold. Figure 6.18 shows that for a Level-0 threshold efficient at 200 GeV (130 GeV online), events have on average 13 jets with $p_T > 20$ GeV.

## 6.8 Boosted-object Triggers

At Level-0, the Global Trigger will reconstruct $R = 1.0$ jets from topoclusters using the anti-$k_t$ algorithm. The resulting performance for this trigger is shown in Fig. 6.22. The 422 topocluster-based jets outperform the gFEX jets give a threshold for 35 kHz of 365 GeV instead of 380 GeV. In order to further reduce the threshold for the same rate, two selections have been found to be very effective in Run 2 and can be implemented in the Global Trigger: jet trimming [6.10] requires that sub-jets within the large-$R$ jet have a minimum fraction of the jet energy to be counted as part of the jet, and jet mass requires that the remaining constituents have a minimum mass. Similar selections are used in offline analysis. Figure 6.23 shows the impact on the efficiency of these two selections on the Run 2 large-$R$ jet trigger.
<figure><img src="image_101.png" /><figcaption>(a) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various minimum track $p_T$ requirements used in the vertex matching. The full $|\eta| < 4.0$ tracker coverage is used.</figcaption></figure>

<figure><img src="image_102.png" /><figcaption>(b) Rate vs offline $E_T^{\text{miss}}$ at which the trigger is 95% efficient for various track $\eta$ coverage assumptions used in the vertex matching. A minimum track $p_T$ of 1 GeV is assumed.</figcaption></figure>

<figure><img src="image_103.png" /><figcaption>(a) Efficiency as a function of true $E_T^{\text{miss}}$ for an $H_T^{\text{miss}}$ variable and an $E_T^{\text{miss}}$ variable which includes the track soft term with tracking coverage over $|\eta| < 4.0$ and a minimum track $p_T$ of 1 GeV.</figcaption></figure>

<figure><img src="image_104.png" /><figcaption>(b) Efficiency as a function of offline $E_T^{\text{miss}}$ for an $H_T^{\text{miss}}$ variable and an $E_T^{\text{miss}}$ variable which includes the track soft term with tracking coverage over $|\eta| < 4.0$ and a minimum track $p_T$ of 2 GeV. The $E_T^{\text{miss}}$ variable with a minimum track $p_T$ of 1 GeV would be by definition a step function at 200 GeV.</figcaption></figure>

<caption>Figure 6.21: Efficiency as a function of true $E_T^{\text{miss}}$ and offline $E_T^{\text{miss}}$ in the Event Filter using global tracking.</caption>
<figure><img src="image_105.png" /><figcaption>Figure 6.22: Level-0 rate and efficiency for a large-R jet trigger. The gFEX algorithm (grey) corresponds to the performance of the Phase-I system. The 422 EM (red) shows the performance of the proposed system which has a lower threshold for the same rate. The blue and green curves show performance of the anti-$k_t$ algorithm applied to the Phase-I granularity (a feature which is only possible in the Phase-II system) which is less performant than the 422 EM based result.</figcaption></figure>

The red line shows the efficiency for large-R jets without additional requirements. The blue line shows the efficiency after adding a jet trimming requirement that sub-jets reconstructed with $R=0.2$ have at least $f = 0.04$ of the total jet energy. The green line shows the efficiency after adding a further jet mass requirement of $m_{jet} > 30$ GeV. The online thresholds for each curve are adjusted to give the same rate, so by adding the two additional requirements, the threshold can be reduced by ≈ 50 GeV. A similar improvement is expected from an implementation in the Global Trigger.

## 6.9 Exotic-object Triggers

As described in Section 2.8, some new physics scenarios produce signatures which are not identified by the standard set of reconstructed objects. There are several on-going activities to address these cases. In particular, the loss of efficiency for near-by muons in the Run 2 and Phase-I system will be addressed with dedicated algorithms to search for second muon candidates near other muon candidates. Other related topics include investigations of delayed muon triggers where an event is triggered by a muon in subsequent event (1-2 bunch crossings later) and high-impact parameter muons, which are due to particles traveling a significant distance from the beam-spot before decaying.
<figure><img src="image_106.png" /><figcaption>Figure 6.23: Trigger efficiency versus offline jet $p_T$ for three large-R triggers in Run 2. The threshold for each selection has be adjusted to give equal trigger rate, so better performance corresponds having efficiency for lower jet $p_T$ for the same rate. The red line shows large-R jets without addition requirements. The blue line adds a jet trimming requirement that sub-jets reconstructed with $R = 0.2$ have at least $f = 0.04$ of the total jet energy. The green line adds a further jet mass requirement of $m_{jet} > 30$ GeV.</figcaption></figure>

## 6.10 Inclusive Vector Boson Fusion Trigger

A study has been conducted to implement an inclusive VBF Higgs trigger assuming that the fFEX provides calorimeter-based jets similar to the offline reconstruction. A candidate selection requires two trigger jets separated in pseudo-rapidity by $\Delta\eta > 2.5$. They are further required not to be back-to-back as in dijet production ($\Delta\phi < 2.5$). The jet $p_T$ threshold was then scanned to explore possible working points. The results show that an acceptance of 6.6% for all Higgs bosons produced by the VBF mechanism can be achieved with a jet $p_T$ requirement of 75 GeV corresponding to a Level-0 rate of 33 kHz, which can be reduced to ~5 kHz by requiring the jets to be consistent with a common z vertex using regional tracking. The cross-section for the VBF process at $\sqrt{s} = 14$ TeV is 4.28 pb [6.11], compared to the WH, $W \to \ell v$ cross-section times branching fraction of 0.34 pb and 0.067 pb for ZH, $Z \to \ell\ell$. The VBF inclusive trigger has comparable sensitivity to WH and far exceeding ZH. Furthermore, because of the neutrino in the leptonic W decay, the WH has a limitation with respect to channels involving $E_T^{miss}$.

This trigger allows 6.6% of the VBF Higgs processes to reach the Event Filter, but in order to read those events out to offline storage, additional analysis-specific requirements will be needed. These additional selections can then take advantage of the Event Filter capabilities, including full-detector tracking at 1 GeV as needed. In the menu presented in Section 6.11,
an Event Filter rate for the resulting trigger is allocated, which would be composed of a large set of analysis-specific selections.

## 6.11 Example Run 4 Trigger Menu

The full set of triggers used in the system is referred to as the menu. The menu, shown in Table 6.4, is constructed to meet the physics requirements given in Chapter 2 and is representative of the primary triggers that would be used. The full trigger menu for Run 2 consists of more than 2000 selections, so Table 6.4 should only be considered as representative.

The procedures used to estimate the rates are described in Section 6.1. The totals shown are the sum of the rates for the individual channels. Some reduction in the total is expected and is due to overlaps between the channels (~ 10 – 20%). In addition, analysis-specific, monitoring, and support triggers would be included in a full menu. The Event Filter rate is near the limit, but the Event Filter system provides the largest flexibility for including additional selections to reduce the rates. If needed, this would include analysis-specific cuts which reduce rates at the expense of the generality of the resulting dataset.

The menu also includes resources reserved for supporting triggers, which enable trigger efficiency measurements and a wide variety of performance measurements. The allocations are based on the fraction of the current Run 2 menu used for supporting triggers at each level (10% at Level-0 and after regional tracking, and 20% in the Event Filter) and are indicated with the "Supporting Trigs" line.

The Phase-II Event Filter menu can be compared to the current Run 2 menu scaled by luminosity. The current Run 2 menu operates at 1500 Hz for a luminosity of $\mathcal{L} = 2.0 \times 10^{34} \text{ cm}^{-2}\text{s}^{-1}$. Scaled to $\mathcal{L} = 7.5 \times 10^{34} \text{ cm}^{-2}\text{s}^{-1}$, this gives 6.6 kHz. The majority of the additional rate in the Phase-II menu comes from these sources:

* Level-0 seeded large-$R$ jets, 0.5 kHz additional rate

* Forward electrons, 0.2 kHz additional rate

* Inclusive VBF triggers, 0.5 kHz additional rate

* Lower single-lepton $p_T$ threshold, 0.9 kHz additional rate

- For comparison, this 30% higher rate gives acceptance gains of 16% for inclusive $W$ and $t\bar{t}$ production, 28% acceptance gain for $HH \to b\bar{b}\tau\tau$ with one $\tau$ decaying to leptons, and 47% for the “Well-tempered neutralino” compressed SUSY model introduced in Section 2.1.

* Lower dilepton $p_T$ thresholds, 0.25 kHz additional rate

- This leads to 70% more VBF $H \to \tau\tau$ acceptance and $\approx 3$ times more acceptance for the SUSY model shown in Fig. 2.4

* More inclusive di-$\tau$ trigger, 0.15 kHz additional rate
<table><caption>Table 6.4: Representative trigger menu for 1 MHz Level-0 rate. The offline $p_T$ thresholds indicate the momentum above which a typical analysis would use the data.</caption><thead><tr><th>Trigger Selection</th><th>Run 1<br>Offline $p_T$<br>Threshold<br>[GeV]</th><th>Run 2 (2017)<br>Offline $p_T$<br>Threshold<br>[GeV]</th><th>Planned<br>HL-LHC<br>Offline $p_T$<br>Threshold [GeV]</th><th>L0<br>Rate<br>[kHz]</th><th>After<br>regional<br>tracking<br>cuts [kHz]</th><th>Event<br>Filter<br>Rate<br>[kHz]</th></tr></thead><tbody><tr><td>isolated single <i>e</i></td><td>25</td><td>27</td><td>22</td><td>200</td><td>40</td><td>1.5</td></tr><tr><td>isolated single <i>&mu;</i></td><td>25</td><td>27</td><td>20</td><td>45</td><td>45</td><td>1.5</td></tr><tr><td>single <i>&gamma;</i></td><td>120</td><td>145</td><td>120</td><td>5</td><td>5</td><td>0.3</td></tr><tr><td>forward <i>e</i></td><td></td><td></td><td>35</td><td>40</td><td>8</td><td>0.2</td></tr><tr><td>di-&gamma;</td><td>25</td><td>25</td><td>25,25</td><td></td><td>20</td><td>0.2</td></tr><tr><td>di-e</td><td>15</td><td>18</td><td>10,10</td><td>60</td><td>10</td><td>0.2</td></tr><tr><td>di-&mu;</td><td>15</td><td>15</td><td>10,10</td><td>10</td><td>2</td><td>0.2</td></tr><tr><td><i>e</i> - <i>&mu;</i></td><td>17,6</td><td>8,25 / 18,15</td><td>10,10</td><td>45</td><td>10</td><td>0.2</td></tr><tr><td>single <i>&tau;</i></td><td>100</td><td>170</td><td>150</td><td>3</td><td>3</td><td>0.35</td></tr><tr><td>di-&tau;</td><td>40,30</td><td>40,30</td><td>40,30</td><td>200</td><td>40</td><td>0.5<sup>+++</sup></td></tr><tr><td>single <i>b</i>-jet</td><td>200</td><td>235</td><td>180</td><td></td><td>25</td><td>0.35<sup>+++</sup></td></tr><tr><td>single jet</td><td>370</td><td>460</td><td>400</td><td>25</td><td>25</td><td>0.25</td></tr><tr><td>large-R jet</td><td>470</td><td>500</td><td>300</td><td>40</td><td>40</td><td>0.5</td></tr><tr><td>four-jet (w/ <i>b</i>-tags)</td><td></td><td>45<sup>&dagger;</sup>(1-tag)</td><td>65(2-tags)</td><td></td><td>20</td><td>0.1</td></tr><tr><td>four-jet</td><td>85</td><td>125</td><td>100</td><td>100</td><td>20</td><td>0.2</td></tr><tr><td>$H_T$</td><td>700</td><td>700</td><td>375</td><td>50</td><td>10</td><td>0.2<sup>+++</sup></td></tr><tr><td>$E_T^{miss}$</td><td>150</td><td>200</td><td>210</td><td>60</td><td>5</td><td>0.4</td></tr><tr><td>VBF inclusive</td><td></td><td></td><td>2x75 w/ (Δη &gt; 2.5<br>&amp; Δφ &lt; 2.5)</td><td>33</td><td>5</td><td>0.5<sup>+++</sup></td></tr><tr><td>B-physics<sup>++</sup></td><td></td><td></td><td></td><td>50</td><td>10</td><td>0.5</td></tr><tr><td>Supporting Trigs</td><td></td><td></td><td></td><td>100</td><td>40</td><td>2</td></tr><tr><td>Total</td><td></td><td></td><td></td><td>1066</td><td>338</td><td>10.4</td></tr></tbody></table>

† In Run 2, the 4-jet b-tag trigger operates below the efficiency plateau of the Level-1 trigger.

†† This is a place-holder for selections to be defined.

††† Assumes additional analysis specific requires at the Event Filter level

The Global Trigger and HTT elements give the proposed system significant flexibility to construct such specialised triggers either to address science goals that are not met by the inclusive object-based selections shown in the example menu, such as exotic signatures, or where inclusive selections have a rate that is too high. This is particularly important for the Event Filter where additional algorithms are not difficult to include provided a large computing cost is not implied. In many cases, the Run 2 performance is limited by the computing cost of tracking which in the upgraded system can be addressed with the HTT.
<table><caption>Table 6.5: Estimation of regional tracking needs. The fourth column indicates the η − φ fraction of the detector for which tracking is needed, but as described in the text, a significantly larger fraction of the data is needed to find the corresponding tracks because of the length of the beam spot in z, the spread of the tracks in φ due to the track curvature, and the effects of module boundaries. The impact of those effects on three example layers are shown in columns 5-7. The small differences between bottom row numbers and the layer by layer maxima in Figure 6.26 are due to a more detailed accounting of the η dependence of the objects for the figure.</caption><thead><tr><th rowspan="2">Trigger Selection</th><th rowspan="2">Object<br>Multiplicity</th><th rowspan="2">Region<br>Size<br>(% detector)</th><th colspan="3">Regional Tracking (rHTT) Need Per Event<br>Detector Data Fraction</th></tr><tr><th>% η − φ<br>coverage</th><th>Pixel<br>Layer 5</th><th>Strip<br>Layer 1</th><th>Strip<br>Layer 4</th></tr></thead><tbody><tr><td>isolated single e</td><td>1</td><td>0.2 × 0.2</td><td>0.13%</td><td>1.0%</td><td>1.3%</td><td>0.4%</td></tr><tr><td>isolated single μ</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>single γ</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>forward e</td><td>1</td><td>0.2 × 0.2</td><td>0.13%</td><td>1.0%</td><td>1.3%</td><td>0.4%</td></tr><tr><td>di-γ</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>di-e</td><td>2</td><td>0.2 × 0.2</td><td>0.25%</td><td>2.0%</td><td>2.6%</td><td>0.8%</td></tr><tr><td>di-μ</td><td>2</td><td>0.2 × 0.2</td><td>0.25%</td><td>2.0%</td><td>2.6%</td><td>0.8%</td></tr><tr><td>e − μ</td><td>2</td><td>0.2 × 0.2</td><td>0.25%</td><td>2.0%</td><td>2.6%</td><td>0.8%</td></tr><tr><td>single τ</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>di-τ</td><td>2</td><td>0.2 × 0.2</td><td>0.25%</td><td>2.0%</td><td>2.6%</td><td>0.8%</td></tr><tr><td>single jet</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>large-R jet</td><td></td><td>Not Used</td><td></td><td></td><td></td><td></td></tr><tr><td>four-jet</td><td>5</td><td>0.8 × 0.8</td><td>10.2%</td><td>23.0%</td><td>25.5%</td><td>14.5%</td></tr><tr><td>H<sub>T</sub></td><td>5</td><td>0.8 × 0.8</td><td>10.2%</td><td>23.0%</td><td>25.5%</td><td>14.5%</td></tr><tr><td>E<sup>miss</sup><sub>T</sub></td><td>3</td><td>0.8 × 0.8</td><td>5.7%</td><td>12.9%</td><td>14.3%</td><td>8.1%</td></tr><tr><td>VBF inclusive</td><td>2</td><td>0.8 × 0.8</td><td>4.1%</td><td>9.2%</td><td>10.2%</td><td>5.8%</td></tr><tr><td>Supporting Trigs</td><td>10% of total rate</td><td></td><td>0.2%</td><td>0.5%</td><td>0.6%</td><td>0.3%</td></tr></tbody><tfoot><tr><td colspan="3">Averages per event weighted by rates</td><td>2.3%</td><td>6.0%</td><td>6.8%</td><td>3.5%</td></tr></tfoot></table>

6.12 Tracking Needs

The rHTT and gHTT are critical to achieving the menu presented in the previous section. An estimate of the tracking rates required to achieve this menu is presented in Tables 6.5 and 6.6 respectively.

The rHTT system provides regional tracking at the full Level-0 accept rate (1 MHz). It uses a reduced set of ITk layers which provides sufficient resolution for verifying the presence of tracks down to 2 GeV and significantly reducing backgrounds which have objects from multiples vertices. Because of the reduced number of layers used by the rHTT system, the resulting tracks are not appropriate for b-tagging. The regional tracking estimate is calcu- lated assuming that e, μ, and τ use η × φ regions that are 0.2 × 0.2, small-R jets use tracking in regions that are 0.8 × 0.8, and large-R jets use tracking in regions that are 2.0 × 2.0. Be-
<table><caption>Table 6.6: Estimation of global tracking needs.</caption><thead><tr><th rowspan="2">Trigger Selection</th><th rowspan="2">Object<br>Multiplicity</th><th rowspan="2">Region<br>Size<br>(% detector)</th><th colspan="2">Global Tracking (gHTT)<br>Need Per Event</th><th rowspan="2">Use Cases</th></tr><tr><th>% η − φ<br>coverage</th><th>Effective Rate<br>(kHz)</th></tr></thead><tbody><tr><td>isolated single <i>e</i></td><td>1</td><td>0.4 × 0.4</td><td>0.51%</td><td>0.20</td><td>isolation</td></tr><tr><td>isolated single <i>μ</i></td><td>1</td><td>0.4 × 0.4</td><td>0.51%</td><td>0.13</td><td>isolation</td></tr><tr><td>single <i>γ</i></td><td>1</td><td>0.4 × 0.4</td><td>0.51%</td><td>0.03</td><td>isolation</td></tr><tr><td>forward <i>e</i></td><td>1</td><td>0.4 × 0.4</td><td>0.51%</td><td>0.04</td><td>isolation</td></tr><tr><td>di-<i>γ</i></td><td>2</td><td>0.4 × 0.4</td><td>1.02%</td><td>0.20</td><td>isolation</td></tr><tr><td>di-<i>e</i></td><td>2</td><td>0.4 × 0.4</td><td>1.02%</td><td>0.10</td><td>isolation</td></tr><tr><td>di-<i>μ</i></td><td>2</td><td>0.4 × 0.4</td><td>1.02%</td><td>0.05</td><td>isolation</td></tr><tr><td><i>e</i> − <i>μ</i></td><td>2</td><td>0.4 × 0.4</td><td>1.02%</td><td>0.10</td><td>isolation</td></tr><tr><td>single <i>τ</i></td><td>1</td><td>0.4 × 0.4</td><td>0.51%</td><td>0.02</td><td>isolation</td></tr><tr><td>di-<i>τ</i></td><td></td><td>full event</td><td>100%</td><td>5</td><td>b-tagging, <i>E</i><sub>T</sub><sup>miss</sup><br>soft-term</td></tr><tr><td>single jet</td><td></td><td>full event</td><td>100%</td><td>25</td><td>b-tagging, soft had-<br>ronic</td></tr><tr><td>large-R jet</td><td>1</td><td>2.0 × 2.0</td><td>13%</td><td>5.1</td><td>b-tagging, pile-up</td></tr><tr><td>four-jet</td><td></td><td>full event</td><td>100%</td><td>20</td><td>b-tagging, soft jets<br>to seed high jet<br>multiplicity</td></tr><tr><td><i>H</i><sub>T</sub></td><td></td><td>full event</td><td>100%</td><td>10</td><td>b-tagging, soft jets<br>to seed high jet<br>multiplicity</td></tr><tr><td><i>E</i><sub>T</sub><sup>miss</sup></td><td></td><td>full event</td><td>100%</td><td>5</td><td>b-tagging, <i>E</i><sub>T</sub><sup>miss</sup> soft<br>term</td></tr><tr><td>VBF inclusive</td><td></td><td>full event</td><td>100%</td><td>5</td><td><i>E</i><sub>T</sub><sup>miss</sup> soft-term, soft<br>jets to seed high jet<br>multiplicity</td></tr><tr><td>Supporting Trigs</td><td></td><td></td><td></td><td>15</td><td>20% of total</td></tr></tbody><tfoot><tr><td colspan="4">Total Rate</td><td>91</td><td></td></tr></tfoot></table>

cause of the beam spot spread in z, the bending of tracks in φ, and the tracking detector module boundaries, significantly more data must be used than is represented by the geometrical η − φ regions for which tracking is needed. To estimate this effect, the frequency that a detector module would be included in a tracking request is calculated for various size objects (0.2 × 0.2, 0.8 × 0.8, or 2.0 × 2.0) distributed uniformly over either |η| < 2.5 or |η| < 4.0. For example, Figures 6.24 shows 0.2 × 0.2 requests distributed over |η| < 2.5 which are relevant for e, μ, and τ objects and Figure 6.25 shows 0.8 × 0.8 request distributed over |η| < 4.0 which are appropriate for jets in $E_T^{\text{miss}}$ calculations. The multiplicities of e, μ, and τ are assumed to be the number in the trigger (a small underestimate). For the multi-jet, $E_T^{\text{miss}}$ triggers, and $H_T$ triggers, the jet multiplicities are estimated from simulation as a function of the $p_T$ relevant for the selection, see Figs. 6.15 and 6.18. For regional tracking, a 50 GeV jet threshold is expected. The result is that averaged over the representative menu,
<figure><img src="image_107.png" /><figcaption>Figure 6.24: Fraction of tracking requests needing a module for 0.2 × 0.2 objects uniformly distributed over $|η| < 2.5$.</figcaption></figure>

approximately 2.3% of $η - φ$ coverage is needed for regional tracking, but the data required for that tracking is as much as 3.5 to 6.8% for the more central modules in the layers used in the rHTT system. This is shown for all the modules positions in the ITK system in Figure 6.26. This figure is constructed by summing readout fraction distributions for individual objects, such as those shown in Figures 6.24 and 6.25, multiplied by the object multiplicity for the event type and the fraction of events for which that trigger is active (there small differences between bottom row numbers in Table 6.5 and the layer by layer maxima in Figure 6.26 due to a more detailed accounting of the $η$ dependence of the objects used in the figure). To leave a margin, and because the menu is not complete, regional tracking is planned to be available for 10% of the detector data per event on average (individual events may have significantly more than the average).

The gHTT system provides high-resolution full-scan tracking down to 1 GeV appropriate for b-tagging either in regions or for the full-detector. The offline reconstruction is also expected to maintain a 1 GeV track threshold [6.12][6.13]. Use cases that are being considered for gHTT include b-tagging and track-based calibration on all jets with $p_T > 20$ GeV, calculation of variables such as the $E_T^{miss}$ soft-term, pile-up correction/mitigation, and searching
<figure><img src="image_108.png" /><figcaption>Figure 6.25: Fraction of tracking requests needing a module for 0.8 × 0.8 objects uniformly distributed over $|η| < 4.0$.</figcaption></figure>

for additional soft-jets using full-detector tracking. Supporting triggers for efficiency calculations and other performance studies are assumed to operate at 20% of the primary triggers. These use cases are based on examination of the current Run 2 menu which has been developed based on extensive collaboration between the trigger group and the data analysis teams. The b-tagging is used in single jet, multi-jet, large-R jet, $E_T^{miss}$, $H_T$, and di-$\tau$ triggers to reduce significantly reduce rates while preserving physics with flavour-specific final states, such as $HH \to 4b$ or $bb\tau\tau$, electroweak SUSY to $4b + E_T^{miss}$, and RPV SUSY. Searching for additional soft-jets in the Run 2 menu is primarily used in the multi-jet triggers where the rate that can be brought to the Event Filter is substantially higher than what can be recorded; in particular, higher jet multiplicity triggers are build on four jet triggers. With the novel VBF inclusive trigger and the $E_T^{miss}$ trigger, it is expected that soft hadronic final states will be important, for example for the search for the exotic Higgs boson decay $H \to 4b$.

Figs. 6.15 and 6.18 show that for both 4-jet and $E_T^{miss}$ events, there are on average 13 jets with $p_T > 20$ GeV. This large number combined with the effect of the beam spot spread in z and the bending of tracks in $\phi$ means that essentially the entire detector is needed for b-tagging