scholarly journals FELIX: the Detector Interface for the ATLAS Experiment at CERN

2021 ◽  
Vol 251 ◽  
pp. 04006
Author(s):  
Alexander Paramonov
Keyword(s):  
Hadron Collider ◽  
Electromagnetic Calorimeter ◽  
Electronic Systems ◽  
Switched Networks ◽  
Atlas Experiment ◽  
Level Trigger ◽  
Data Links ◽  
System Memory ◽  
Commodity Computing ◽  
High Level

The Front-End Link eXchange (FELIX) system is an interface between the trigger and detector electronics and commodity switched networks for the ATLAS experiment at CERN. In preparation for the LHC Run 3, to start in 2022, the system is being installed to read out the new electromagnetic calorimeter, calorimeter trigger, and muon components being installed as part of the ongoing ATLAS upgrade programme. The detector and trigger electronic systems are largely custom and fully synchronous with respect to the 40.08 MHz clock of the Large Hadron Collider (LHC). The FELIX system uses FPGAs on server-hosted PCIe boards to pass data between custom data links connected to the detector and trigger electronics and host system memory over a PCIe interface then route data to network clients, such as the Software Readout Drivers (SW ROD), via a dedicated software platform running on these machines. The SW RODs build event fragments, buffer data, perform detector-specific processing and provide data for the ATLAS High Level Trigger. The FELIX approach takes advantage of modern FPGAs and commodity computing to reduce the system complexity and effort needed to support data acquisition systems in comparison to previous designs. Future upgrades of the experiment will introduce FELIX to read out all other detector components.

scholarly journals The ATLAS electron and photon trigger performance in Run 2

2020 ◽  
Vol 35 (34n35) ◽  
pp. 2044007
Author(s):  
Daniela Maria Köck
Keyword(s):  
Large Hadron Collider ◽  
Hadron Collider ◽  
Final States ◽  
Atlas Experiment ◽  
Level Trigger ◽  
Level 1 ◽  
High Level ◽  
Electron And Photon

Electron and photon triggers are an important part of many physics analyses at the ATLAS experiment, where electron and photon final states are considered. Understanding the performance of electron and photon triggers at the High Level trigger as well as the Level-1 trigger was crucial to improve and adapt the trigger during changing run conditions of the Large Hadron Collider in Run 2 (2015–2018).

scholarly journals Software Based Control and Monitoring of a Hardware Based Track Reconstruction System for the ATLAS Experiment

2019 ◽  
Vol 214 ◽  
pp. 01021
Author(s):  
Simone Sottocornola
Keyword(s):  
Hadron Collider ◽  
Track Reconstruction ◽  
Trigger System ◽  
Proton Proton ◽  
Good Efficiency ◽  
Atlas Experiment ◽  
Level Trigger ◽  
High Level ◽  
Monitoring Information ◽  
Fast Tracker

During Run 2 of the Large Hadron Collider (LHC) the instantaneous luminosity exceeded the nominal value of 1034 cm−2 s−1 with a 25 ns bunch crossing period and the number of overlapping proton-proton interactions per bunch crossing increased to a maximum of about 80. These conditions pose a challenge to the trigger system of the experiments that has to manage rates while keeping a good efficiency for interesting physics events. This document summarizes the software based control and monitoring of a hardware-based track reconstruction system for the ATLAS experiment, called Fast Tracker (FTK), composed of associative memories and FPGAs operating at the rate of 100 kHz and providing high quality track information within the available latency to the high-level trigger. In particular, we will detail the commissioning of the FTK within the ATLAS online software system presenting the solutions adopted for scaling up the system and ensuring robustness and redundancy. We will also describe the solutions to challenges such as controlling the occupancy of the buffers, managing the heterogeneous and large configuration, and providing monitoring information at sufficient rate.

scholarly journals ATLAS Sim@P1 upgrades during long shutdown two

2020 ◽  
Vol 245 ◽  
pp. 07044
Author(s):  
Frank Berghaus ◽  
Franco Brasolin ◽  
Alessandro Di Girolamo ◽  
Marcus Ebert ◽  
Colin Roy Leavett-Brown ◽  
...  
Keyword(s):  
Large Hadron Collider ◽  
Data Acquisition ◽  
Process Simulation ◽  
Hadron Collider ◽  
Simulation Data ◽  
Level Trigger ◽  
Offline Processing ◽  
High Level

The Simulation at Point1 (Sim@P1) project was built in 2013 to take advantage of the ATLAS Trigger and Data Acquisition High Level Trigger (HLT) farm. The HLT farm provides around 100,000 cores, which are critical to ATLAS during data taking. When ATLAS is not recording data, such as the long shutdowns of the LHC, this large compute resource is used to generate and process simulation data for the experiment. At the beginning of the second long shutdown of the large hadron collider, the HLT farm including the Sim@P1 infrastructure was upgraded. Previous papers emphasised the need for simple, reliable, and efficient tools and assessed various options to quickly switch between data acquisition operation and offline processing. In this contribution, we describe the new mechanisms put in place for the opportunistic exploitation of the HLT farm for offline processing and give the results from the first months of operation.

scholarly journals Experience with dynamic resource provisioning of the CMS online cluster using a cloud overlay

2019 ◽  
Vol 214 ◽  
pp. 07017
Author(s):  
Jean-Marc Andre ◽  
Ulf Behrens ◽  
James Branson ◽  
Philipp Brummer ◽  
Olivier Chaze ◽  
...  
Keyword(s):  
Virtual Machines ◽  
Hadron Collider ◽  
A Priori ◽  
Resource Provisioning ◽  
Static Mode ◽  
Level Trigger ◽  
Network Connection ◽  
Use Of Resources ◽  
Dynamic Resource Provisioning ◽  
High Level

The primary goal of the online cluster of the Compact Muon Solenoid (CMS) experiment at the Large Hadron Collider (LHC) is to build event data from the detector and to select interesting collisions in the High Level Trigger (HLT) farm for offline storage. With more than 1500 nodes and a capacity of about 850 kHEPSpecInt06, the HLT machines represent similar computing capacity of all the CMS Tier1 Grid sites together. Moreover, it is currently connected to the CERN IT datacenter via a dedicated 160 Gbps network connection and hence can access the remote EOS based storage with a high bandwidth. In the last few years, a cloud overlay based on OpenStack has been commissioned to use these resources for the WLCG when they are not needed for data taking. This online cloud facility was designed for parasitic use of the HLT, which must never interfere with its primary function as part of the DAQ system. It also allows to abstract from the different types of machines and their underlying segmented networks. During the LHC technical stop periods, the HLT cloud is set to its static mode of operation where it acts like other grid facilities. The online cloud was also extended to make dynamic use of resources during periods between LHC fills. These periods are a-priori unscheduled and of undetermined length, typically of several hours, once or more a day. For that, it dynamically follows LHC beam states and hibernates Virtual Machines (VM) accordingly. Finally, this work presents the design and implementation of a mechanism to dynamically ramp up VMs when the DAQ load on the HLT reduces towards the end of the fill.

scholarly journals The muon high level trigger of the ATLAS experiment

2010 ◽  
Vol 219 (3) ◽  
pp. 032025
Author(s):  
Andrea Ventura ◽  
the Atlas Collaboration
Keyword(s):  
Atlas Experiment ◽  
Level Trigger ◽  
High Level

scholarly journals Configuration and scheduling of the LHCb trigger application

2020 ◽  
Vol 245 ◽  
pp. 05004
Author(s):  
Rosen Matev ◽  
Niklas Nolte ◽  
Alex Pearce
Keyword(s):  
Hadron Collider ◽  
Research Programme ◽  
Control Flow ◽  
Data Flow Graph ◽  
Level Trigger ◽  
Form Part ◽  
Order Of Magnitude ◽  
High Level ◽  
User Friendly ◽  
And Control

For Run 3 of the Large Hadron Collider, the final stage of the LHCb experiment’s high-level trigger must process 100 GB/s of input data. This corresponds to an input rate of 1 MHz, and is an order of magnitude larger compared to Run 2. The trigger is responsible for selecting all physics signals that form part of the experiment’s broad research programme, and as such defines thousands of analysis-specific selections that together comprise tens of thousands of algorithm instances. The configuration of such a system needs to be extremely flexible to be able to handle the large number of different studies it must accommodate. However, it must also be robust and easy to understand, allowing analysts to implement and understand their own selections without the possibility of error. A Python-based system for configuring the data and control flow of the Gaudi-based trigger application is presented. It is designed to be user-friendly by using functions for modularity and removing indirection layers employed previously in Run 2. Robustness is achieved by reducing global state and instead building the data flow graph in a functional manner, whilst keeping configurability of the full call stack.

scholarly journals FELIX: the new detector interface for the ATLAS experiment

2019 ◽  
Vol 214 ◽  
pp. 01023
Author(s):  
Nikolina Ilic ◽  
Jos Vermeulen ◽  
Serguei Kolos
Keyword(s):  
Control Systems ◽  
Serial Links ◽  
Specific Data ◽  
Atlas Experiment ◽  
Switched Network ◽  
Level Trigger ◽  
Front End ◽  
High Bandwidth ◽  
High Level ◽  
And Control

During the next major shutdown from 2019-2020, the ATLAS experiment at the LHC at CERN will adopt the Front-End Link eXchange (FELIX) system as the interface between the data acquisition, detector control and TTC (Timing, Trigger and Control) systems and new or updated trigger and detector front-end electronics. FELIX will function as a router between custom serial links from front end ASICs and FPGAs to data collection and processing components via a commodity switched network. Links may aggregate many slower links or be a single high bandwidth link. FELIX will also forward the LHC bunch-crossing clock, fixed latency trigger accepts and resets received from the TTC system to front-end electronics. The FELIX system uses commodity server technology in combination with FPGA-based PCIe I/O cards. The FELIX servers will run a software routing platform serving data to network clients. Commodity servers connected to FELIX systems via the same network will run the new Software Readout Driver (SW ROD) infrastructure for event fragment building and buffering, with support for detector or trigger specific data processing, and will serve the data upon request to the ATLAS High-Level Trigger for Event Building and Selection. This proceeding will cover the design and status of FELIX and the SW ROD.

scholarly journals A new approach for ATLAS Athena job configuration

2019 ◽  
Vol 214 ◽  
pp. 05015 ◽  
Author(s):  
Walter Lampl
Keyword(s):  
Flow Simulation ◽  
Simulated Data ◽  
Work Flow ◽  
Software Framework ◽  
New Approach ◽  
Atlas Experiment ◽  
Level Trigger ◽  
Configuration System ◽  
Full Power ◽  
High Level

The offline software framework of the ATLAS experiment (Athena) consists of many small components of various types like Algorithm, Tool or Service. To assemble these components into an executable application for event processing, a dedicated configuration step is necessary. The configuration of a particular job depends on the work-flow (simulation, reconstruction, high-level trigger, overlay, calibration, analysis ...) and the input data (real or simulated data, beam-energy, ...). The configuration step is done by executing python code. The resulting config-uration depends on optionally pre-set flags as well as meta-data about the data to be processed. For the python configuration code, there is almost no structure enforced, leaving the full power of python to the user. While this approach did work, it also proved to be error prone and complicated to use. It also leads to jobs containing more components that they actually need. For LHC Run 3 a more robust system is envisioned. It is still based on python but enforces a structure and emphasis modularity. This contribution briefly reports about the configuration system used during LHC Run 1 and Run 2 and details the prototype of an improved system to be used in Run 3 and beyond.

Sign in / Sign up

Export Citation Format

Share Document