AliRoot Data Processing Flow

Data processing in AliRoot is mainly divided into three major parts: simu-lation, reconstruction and analysis ([13]). There is also satellite functionality like e.g. event visualization. The overall data flow is sketched in Figure 4.9.

Within that scheme, the reconstruction step takes its input either from sim-ulation of the detector response or real data. Event reconstruction is a cen-trally managed layer which usually hides all detector raw data, calibration and alignment processes from the end-user doing the subsequent analysis. It produces a detailed summary of the event, the Event Summary Data (ESD), containing all information on particles found in the event. The last step, the actual physics analysis is naturally distributed and diversified as it depends on many different interests. Based on the ESD, any physics analysis can be run independently of both simulation and reconstruction.

AliRoot simulation

Event reconstruction Analysis

Analysis

Analysis Analysis Analysis

Analysis ESD

Figure 4.9: Overall AliRoot processing sequence. Event reconstruction is per-formed on either real raw data or simulated data and producesEvent Summary Data (ESD)which is the input to the subsequent analysis.

In a complex data analysis system it is important to study the behavior of the different modules and the system response with respect to known input separately in order to assure the result of the entire analysis. This is in particular important in an experiment like ALICE where the physics going to be studied can only be ’seen’ through secondary processes and require a complex data processing. The impact of the measuring apparatus and the data processing on the measured quantity needs to be studied carefully. Usually in electronics engineering, the input to a certain signal processing unit is known and can be compared directly to the output. This is not the case for the considered type of experiment.

Analysis of simulated events is thus required to study the behavior and per-formance of the detector reconstruction. Only after evaluation of the

algo-rithms with high statistics it makes sense to process real data. For simulated events, the result of the reconstruction and analysis can be compared to the original simulated events. This approach is similar to signal response studies used in electronics engineering.

HLT has a special position within the described AliRoot processing chain.

As a matter of fact, HLT always runs event reconstruction since it is not a sub-detector delivering data. Consequently, it needs to run at the end of the AliRoot simulation when data for all sub-detectors has been generated. Em-bedded into AliRoot simulation, this reconstruction is performed on simulated data. It is often referred to be HLT simulation. Figure 4.10 sketches the data flow for HLT simulation.

Figure 4.10: HLT simulation in AliRoot.

The lower block denoted HLT system in Figure 4.10 implements an encap-sulated HLT analysis with well defined input and output. It is important to notice that the placement of HLT analysis is flexible and just depending on the availability of customized input data sources and output data sinks. This concept follows the High-Level Trigger design as outlined in Sec. 3.3.1.

Since HLT reconstruction has already been executed either as part of simu-lation or on-line data processing, the result just needs to be extracted during AliRoot reconstruction and stored appropriately. The treatment of HLT out-put is described in chapter 5.

Abstract Data Access

The AliRoot software package is organized into steering libraries, providing common functionality, and detector module libraries. Two abstraction layers form the foundation of the modular AliRoot data processing architecture:

• The detector modules follow a plug-in concept in order to provide the detector specific simulation and reconstruction.

• AliRoot provides abstract interfaces for data access which disentangle data processing and all necessary steps of data storage and transporta-tion.

The exact format of data in the different steps of the processing chain will be explained later in the corresponding sections 4.5.3 and 4.5.4. However, the two interfaces for data access in AliRoot will be introduced already here for better understanding.

The RunLoader Interface

In the course of AliRoot simulation, first particles are “generated” and the response of the detector to those virtual events is simulated. Data of inter-mediate stages are stored in a tree structure in proprietary ROOT files. The common denominator for all detector modules is a naming scheme for trees, branches and files. The AliRunLoader provides the interface to the data sets of the different stages.

The RunLoader concept is not of major importance for the ALICE HLT and is mentioned here for completeness.

The RawReader Interface

Each detector defines its own raw data format. Because of that, data trans-portation and storage treats detector raw data as payload. Following the hardware solution of DDLs as described in section 3.3.2, the data flow is grouped in entities of DDL blocks. Each data block has a Common Data Header (CDH), which contains all relevant properties of the block like, e.g.

size and trigger information. The format of the CDH is described in [32] and sketched in figure 4.11. Out of the eight 32 ˙bit words, word 0 containing the block length and the Error and Status bits in word 4 are of interest for the HLT. Furthermore the event id and trigger information is used by the data transport framework for data flow control.

word #3

Format Version [31−24] L1 trigger [21−14]

Status and Error bits [27−12]

Trigger classes [31−0]

Figure 4.11: The Common Data Header (CDH) consists of eight 32 ˙bit words.

Access to raw data is generalized by the AliRoot class AliRawReader Raw data are formatted in various representations throughout the processing. Fig-ure 4.12 illustrates the implementations for different formats.

raw DDL buffers

Figure 4.12: The AliRawReader interface. Different implementations of readers fit different raw data representations.

The ALICE DAQ formats DDL data blocks as received from the Detector Data Links in a proprietary data format, a so called Date file. For final storage, those files are converted into the ROOT file format. In the particular case of ALICE, payload of each DDL is stored in branches of a tree⁶. On the way to the Date file, raw data first exists in the form of raw data blocks. In case of simulation, these raw data blocks are written to disk in separate files.

For all those formats, the class AliRawReader provides an abstract access layer. Applications just use the interface, the actual access details are hidden

6TheTTreeconcept is a fundamental feature of the ROOT storage

(Figure 4.12). For HLT, the AliRawReaderMemory has been implemented in the course of the presented work. It allows to feed a number of data blocks into the RawReader and make the payload accessible for the application. It is the prerequisite for both (i) utilization of raw data decoding classes from the off-line project and (ii) running off-line detector algorithms embedded in an analysis component.