Due to the high bunch crossing rate (40 MHz) in the LHC and several megabits of generated data for each bunch crossing it is obvious that the data set measured in the ATLAS detector is too large to be recorded on physical storage for each event. The purpose of the trigger system is to reduce the total data flow by distinguishing only the interesting physics events. The ATLAS trigger system consists of three main levels: Level 1 trigger where the triggering logic is based on the use of dedicated electronics, Level 2 trigger and Event Filtering levels using software algorithms. In each level the decision made in the previous level is refined and additional selection criteria are applied if necessary. A schematic view of the ATLAS trigger system is illustrated in Figure 1.5 [13].
Figure 1.5: The ATLAS trigger system.
Level 1 trigger represents the hardware based trigger which reduces the LHC bunch crossing rate of 40 MHz to a data rate of interesting events of ap- proximately 75 kHz (event processing time ≈2.5às). The Level 1 trigger uses the information from the electromagnetic and hadronic calorimeters and from the muon system (RPC and TGC chambers) to identify the electrons, photons,
high pT muons, τ leptons decaying into hadrons and products with large missing transverse energy (ETmiss) produced from the proton-proton collisions. In addi- tion the Level 1 trigger defines the Regions of Interest (RoI) (the region where the interesting feature was detected) in each event giving the geographical coor- dinates of this regions in η and φ and including the information about the type of the feature and the selection criteria of this region. All this information is transferred to the Level 2 trigger.
Level 2 trigger is a software based trigger using algorithms to analyse the data from the Level 1 trigger and it further reduces the data rate to approximately 2 kHz (event processing time ≈40 ms). Level 2 trigger uses in addition data from the precise MDT and CSC muon chambers for better momentum estimation and information from the inner detector about the reconstructed track.
Event Filteruses more complicated and complex software algorithms to do the event identification. All events passing this final stage are then recorded to the data storage and are available for the offline physics analyses. In this stage the event rate is reduced to approximately 200 Hz with the event processing time
≈4 s, this corresponds to a stored data rate of ≈100 Mbs−1. Since this stage of analysis requires large computing resources event filter runs on several computers located in the CERN computer farm.
Readout and Data Acquisition. Events accepted by the Level 1 trigger are transfered from the front-end electronics into the Readout Drivers (RODs) [13]
and afterwards to the Readout Buffers (ROBs) [13], where they are analysed and stored until the Level 2 trigger accepts or rejects the event. These digital signals represent specially formated raw data ready to be transfered to the Data Acqui- sition (DAQ) system. On the first stage of the DAQ data received and stored in RODs and temporary ROB buffers is analysed by the Level 2 trigger, with the additional information about the RoIs, and accepted events are transferred to the event building system. Afterwards the data is sent to the event filter stage for the final event selection. Events selected by the final stage event filter are transfered
to the CERN computer center and are stored permanently and are available for physics analyses. For the data flow in the ATLAS trigger and DAQ system see Figure 1.5 [13].
The Detector Control System (DCS) is used to ensure logical and safe operation of the ATLAS detector. The DCS allows control, monitor and archive of the different operation parameters for the ATLAS sub-detectors and the technical infrastructure of the experiment. This allows the diagnostic and error recovery of the system, which is implemented through the software platform PVSSII [14]
based user interface (Finite State Machine (FSM) [15] panel). The DCS also controls the detector operation experts and the detector operation monitoring shifters systems; enables the communication between the detector and the data acquisition system, allowing synchronisation between the data-taking and the detector state and manages the communication between ATLAS and the inde- pendently controlled systems like LHC accelerator, technical services and the detector safety system (DSS). The block diagram of the DCS architecture is pre- sented in Figure 1.6 [6].
The screen shot of the ATLAS FSM control panel (the main branch) is pre- sented in Figure 1.7.
Figure 1.6: Architecture of the DCS.
Figure 1.7: The screen shot of the ATLAS FSM control panel.
The Off-line framework. The software framework called Athena [16] is used to analyse the huge amount of recorded data from the ATLAS detector. This framework is designed for the reconstruction of the events from the recorded data and for the simulation of collision events in the ATLAS detector. For these pur- poses the software framework uses special software packages such as Pythia [17]
and GEANT4 [18]. For both the reconstruction and the simulation processes huge amounts of additional information is needed, for example the detailed de- scription of the detector; material description of the sub-detectors, calorimeter and muon system; alignment of the muon structure; state of the magnets and magnetic field; condition of the beam and much more. This kind of information is stored in the on-line database and is updated regularly. The event simulation process consists of several steps including: the simulation of the collision itself, the simulation of the generated particles interacting with the detector material and the simulation of the response of the detector. The various algorithms are employed for the event reconstruction process using the detector response data;
both the real (recorded) or the specially simulated data.