A. Dos Anjos

The base-line DataFlow system of the ATLAS trigger and DAQ

The base-line design and implementation of the ATLAS DAQ DataFlow system is described. The main components of the DataFlow system, their interactions, bandwidths, and rates are discussed and performance measurements on a 10% scale prototype for the final ATLAS TDAQ DataFlow system are presented. This prototype is a combination of custom design components and of multithreaded software applications implemented in C++ and running in a Linux environment on commercially available PCs interconnected by a fully switched gigabit Ethernet network.

The Configuration System of the ATLAS Trigger

The ATLAS detector at CERNs LHC will be exposed to proton-proton collisions at a rate of 40 MHz. To reduce the data rate, only potentially interesting events are selected by a three-level trigger system. The first level is implemented in custom-made electronics, with an output rate to less than 100 kHz. The second and third level are software triggers with a final output rate of 100 to 200 Hz. A system has been designed and implemented that holds and records the full configuration information of all three trigger levels at a centrally maintained location. This system provides fast access to consistent configuration information of the online trigger system for the purpose of data taking as well as to all parts of the offline trigger simulation. The use of relational database technology provides a means of reliable recording of the trigger configuration history over the lifetime of the experiment. In addition to the online system, tools for flexible browsing and manipulation of trigger configurations, and for their distribution across the ATLAS reconstruction sites have been developed. The usability of this design has been demonstrated in dedicated configuration tests of the ATLAS level-1 Central Trigger and of a 600-node software trigger computing farm. Further tests on a computing cluster which is part of the final high level trigger system were also successful.

Studies for a common selection software environment in ATLAS: from the level-2 trigger to the offline reconstruction

The ATLAS High Level Triggers (HLT) primary function of event selection will be accomplished with a Level-2 trigger farm and an event filter (EF) farm, both running software components developed in the ATLAS offline reconstruction framework. While this approach provides a unified software framework for event selection, it poses strict requirements on offline components critical for the Level-2 trigger. A Level-2 decision in ATLAS must typically be accomplished within 10 ms and with multiple event processing in concurrent threads. To address these constraints, prototypes have been developed that incorporate elements of the ATLAS data flow, high level trigger, and offline framework software. To realize a homogeneous software environment for offline components in the HLT, the Level-2 Steering Controller was developed. With electron/gamma- and muon-selection slices it has been shown that the required performance can be reached, if the offline components used are carefully designed and optimized for the application in the HLT.

Performance of the final Event Builder for the ATLAS Experiment

Event data from proton-proton collisions at the LHC will be selected by the ATLAS experiment in a three level trigger system, which reduces the initial bunch crossing rate of 40 MHz at its first two trigger levels (LVL1+LVL2) to ~3 kHz. At this rate the Event-Builder collects the data from all read-out system PCs (ROSs) and provides fully assembled events to the the event-filter (EF), which is the third level trigger, to achieve a further rate reduction to ~ 200 Hz for permanent storage. The event-builder is based on a farm of O(100) PCs, interconnected via gigabit Ethernet to O(150) ROSs. These PCs run Linux and multi-threaded software applications implemented in C++. All the ROSs and one third of the event-builder PCs are already installed and commissioned. We report on performance tests on this initial system, which show promising results to reach the final data throughput required for the ATLAS experiment.

Architecture of the ATLAS High Level Trigger Event Selection Software

We present an overview of the strategy for Event Selection at the ATLAS High Level Trigger and describe the architecture and main components of the software developed for this purpose.

Overview of the high-level trigger electron and photon selection for the ATLAS experiment at the LHC

The ATLAS experiment is one of two general purpose experiments to start running at the Large Hadron Collider in 2007. The short bunch crossing period of 25 ns and the large background of soft-scattering events overlapped in each bunch crossing pose serious challenges that the ATLAS trigger must overcome in order to efficiently select interesting events. The ATLAS trigger consists of a hardware-based first-level trigger and of a software-based high-level trigger, which can be further divided into the second-level trigger and the event filter. This paper presents the current state of development of methods to be used in the high-level trigger to select events containing electrons or photons with high transverse momentum. The performance of these methods is presented, resulting from both simulation studies, timing measurements, and test beam studies.

Design, deployment and functional tests of the online event filter for the ATLAS experiment at LHC

The Event Filter (EF) selection stage is a fundamental component of the ATLAS Trigger and Data Acquisition architecture. Its primary function is the reduction of data flow and rate to values acceptable by the mass storage operations and by the subsequent offline data reconstruction and analysis steps. The computing instrument of the EF is organized as a set of independent subfarms, each connected to one output of the Event Builder (EB) switch fabric. Each subfarm comprises a number of processors analyzing several complete events in parallel. This paper describes the design of the ATLAS EF system, its deployment in the 2004 ATLAS combined test beam together with some examples of integrating selection and monitoring algorithms. Since the processing algorithms are not explicitly designed for EF but are adapted from the offline ones, special emphasis is reserved to system reliability and data security, in particular for the case of failures in the processing algorithms. Other key design elements have been system modularity and scalability. The EF shall be able to follow technology evolution and should allow for using additional processing resources possibly remotely located

Portable Gathering System for Monitoring and Online Calibration at ATLAS.

During the runtime of any experiment, a central monitoring system that detects problems as soon as they appear has an essential role. In a large experiment, like ATLAS, the online data acquisition system is distributed across the nodes of large farms, each of them running several processes that analyse a fraction of the events. In this architecture, it is necessary to have a central process that collects all the monitoring data from the different nodes, produces full statistics histograms and analyses them. In this paper we present the design of such a system, called the gatherer. It allows to collect any monitoring object, such as histograms, from the farm nodes, from any process in the

The ATLAS Event Builder

Event data from proton-proton collisions at the LHC will be selected by the ATLAS experiment in a three-level trigger system, which, at its first two trigger levels (LVL1+LVL2), reduces the initial bunch crossing rate of 40 MHz to ~3 kHz. At this rate, the Event Builder collects the data from the readout system PCs (ROSs) and provides fully assembled events to the Event Filter (EF). The EF is the third trigger level and its aim is to achieve a further rate reduction to ~200 Hz on the permanent storage. The Event Builder is based on a farm of 0(100) PCs, interconnected via a Gigabit Ethernet to 0(150) ROSs. These PCs run Linux and multi-threaded software applications implemented in C++. All the ROSs, and substantial fractions of the Event Builder and Event Filter PCs have been installed and commissioned. We report on performance tests on this initial system, which is capable of going beyond the required data rates and bandwidths for Event Building for the ATLAS experiment.

Online muon reconstruction in the ATLAS level-2 trigger system

To cope with the 40 MHz event production rate of LHC, the trigger of the ATLAS experiment selects events in three sequential steps of increasing complexity and accuracy whose final results are close to the offline reconstruction. The Level-1, implemented with custom hardware, identifies physics objects within Regions of Interests and operates with a first reduction of the event rate to 75 kHz. The higher trigger levels, Level-2 and Level-3, provide a software based event selection which further reduces the event rate to about 100 Hz. This paper presents the algorithm (/spl mu/Fast) employed at Level-2 to confirm the muon candidates flagged by the Level-1. /spl mu/Fast identifies hits of muon tracks inside the barrel region of the Muon Spectrometer and provides a precise measurement of the muon momentum at the production vertex. The algorithm must process the Level-1 muon output rate (/spl sim/20 kHz), thus particular care has been taken for its optimization. The result is a very fast track reconstruction algorithm with good physics performance which, in some cases, approaches that of the offline reconstruction: it finds muon tracks with an efficiency of about 95% and computes p/sub T/ of prompt muons with a resolution of 5.5% at 6 GeV and 4.0% at 20 GeV. The algorithm requires an overall execution time of /spl sim/1 ms on a 100 SpecInt95 machine and has been tested in the online environment of the Atlas detector test beam.