J.M. de Seixas

The ATLAS central level-1 trigger logic and TTC system

The ATLAS central level-1 trigger logic consists in the Central Trigger Processor and the interface to the detector-specific muon level-1 trigger electronics. It is responsible for forming a level-1 trigger in the ATLAS experiment. The distribution of the timing, trigger and control information from the central trigger processor to the readout electronics of the ATLAS subdetectors is done with the TTC system. Both systems are presented.

Online particle detection with Neural Networks based on topological calorimetry information

This paper presents the latest results from the Ringer algorithm, which is based on artificial neural networks for the electron identification at the online filtering system of the ATLAS particle detector, in the context of the LHC experiment at CERN. The algorithm performs topological feature extraction using the ATLAS calorimetry information (energy measurements). The extracted information is presented to a neural network classifier. Studies showed that the Ringer algorithm achieves high detection efficiency, while keeping the false alarm rate low. Optimizations, guided by detailed analysis, reduced the algorithm execution time by 59%. Also, the total memory necessary to store the Ringer algorithm information represents less than 6.2 percent of the total filtering system amount.

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.

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.

The ATLAS level-1 central trigger system

The central part of the ATLAS level-1 trigger system consists of the central trigger processor (CTP), the local trigger processors (LTPs), the timing, trigger and control (TTC) system, and the read-out driver busy (ROD/spl I.bar/BUSY) modules. The CTP combines information from calorimeter and muon trigger processors, as well as from other sources and makes the final level-1 accept decision (L1A) on the basis of lists of selection criteria, implemented as a trigger menu. Timing and trigger signals are fanned out to about 40 LTPs which inject them into the sub-detector TTC partitions. The LTPs also support stand-alone running and can generate all necessary signals from memory. The TTC partitions fan out the timing and trigger signals to the sub-detector front-end electronics. The ROD-BUSY modules receive busy signals from the front-end electronics and send them to the CTP (via an LTP) to throttle the generation of L1As. An overview of the ATLAS level-1 central trigger system will be presented, with emphasis on the design and tests of the CTP modules.

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.

The ATLAS Level-1 central trigger processor

ATLAS is a multi-purpose particle physics detector at CERNs Large Hadron Collider where two pulsed beams of protons are brought to collision at very high energy. There are collisions every 25 ns, corresponding to a rate of 40 MHz. A three-level trigger system reduces this rate to about 200 Hz while keeping bunch crossings which potentially contain interesting processes. The Level-1 trigger, implemented in electronics and firmware, makes an initial selection in under 2.5 mus with an output rate of less than 100 kHz. A key element of this is the central trigger processor (CTP) which combines trigger information from the calorimeter and muon trigger processors to make the final Level-1 accept decision in under 100 ns on the basis of lists of selection criteria, implemented as a trigger menu. Timing and trigger signals are fanned out to all sub-detectors, while busy signals from all sub-detector read-out systems are collected and fed into the CTP in order to throttle the generation of Level-1 triggers

The ATLAS local trigger processor (LTP)

The local trigger processor (LTP) receives timing and trigger signals from the central trigger processor (CTP) and injects them into the timing, trigger and control (TTC) system of a sub-detector front-end TTC partition. The LTP allows stand-alone running by using local timing and trigger signals or by generating them from memory. In addition, several LTPs of the same sub-detector can be daisy-chained. The LTP can thus be regarded as a switching element for timing and trigger signals with input from the CTP or the daisy-chain, from local input, or from the internal data generator, and with output to the daisy-chain, to the TTC partition, or to local output. Finally, in combined mode several LTPs can be connected together using their local outputs and local inputs to allow stand-alone running of combinations of different sub-detectors.

Passive Sonar Signal Detection and Classification Based on Independent Component Analysis

Sonar systems use the sound propagation in underwater environments for detection, communication and navigation. The main purpose of these systems is to analyse the underwater acoustic waves received from different directions by a sensor system and identify the type of target that has been detected in a given direction. Sonar systems may either be passive or active. Both passive and active sonar systems are mainly employed in military settings, although they are also used in commercial and scientific applications, e.g. detecting shoal fishes, performing tomography on sea to exploit a given area, to measure the depth of a region, and so on (Burdic, 1991). In order to detect and classify signals against background noise, passive sonar systems (Waite, 2003) listen to the noise radiated by targets (ships or submarines) using an array of hydrophones. The background noise may be produced by the sea ambient noise or the self-noise of the sonar platform. From the acquired signals, the direction of arrival (DOA) is estimated, in order to inform the eventual presence of a target in a determined direction (bearing). After DOA estimation, relevant features of the target may be extracted from a given direction. There are two types of analysis that can be implemented to obtain the signal relevant features: DEMON (Detection Envelope Modulation On Noise) (Nielsen, 1991) and LOFAR (Low Frequency Analysis and Recording) (Di Martino, 1993). The DEMON is a narrowband analysis that furnishes the propeller characteristic: number of shafts, shaft rotation frequency and blade rate of the target. On the other hand, LOFAR, which is a broadband analysis, estimates the noise vibration of the target machinery. Both analysis are based on spectral estimation and support detection and classification of targets. Depending on the bearing resolution, signal interference may occur for neighbour directions, which contaminates the acquired signals and makes even more difficult the target detection and classification tasks. To minimize these interferences, algorithms using ICA (Independent Component Analysis) (Hyvarinen, 2001), ( Jutten, 2004) may be applied to recover the original sources of the resulting signal mixture and obtain optimal target detection and classification for each direction. The detection is implemented using the classical signal demodulation to obtain the propeller characteristics. On the other hand, efficient classification is often obtained through neural 5

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