• Aucun résultat trouvé

Trigger information data flow for the ATLAS EventIndex


Academic year: 2022

Partager "Trigger information data flow for the ATLAS EventIndex"

En savoir plus ( Page)

Texte intégral


Proceedings of the VIII International Conference "Distributed Computing and Grid-technologies in Science and Education" (GRID 2018), Dubna, Moscow region, Russia, September 10 - 14, 2018



Mikhail Mineev

1, a

, Fedor Prokoshin

2, b

, Alexander Yakovlev


(on behalf of the ATLAS Collaboration)

1 Joint Institute for Nuclear Research, Dubna, Russia

2 Centro Científico Tecnológico de Valparaíso-CCTVal, Universidad Técnica Federico Santa María, Valparaiso, Chile

E-mail: a mineev@jinr.ru, b fedor.prokoshin@cern.ch

Trigger information is an important part of the ATLAS event data. In the EventIndex trigger information is collected for various use cases, including event selection and overlap counting.

Decoding trigger information from the event records, stored as a bit mask, requires additional input from the condition database and the Monte Carlo trigger database, as trigger configurations evolve with time. Trigger information decoding depends on the run number for the recorded data and from the settings for Monte Carlo simulation. This article describes trigger information handling in the EventIndex and the interfaces used to access it.

Keywords: trigger information, ATLAS detector, EventIndex, HBase, EITrigDB library

© 2018 Mikhail Mineev, Fedor Prokoshin, Alexander Yakovlev


Proceedings of the VIII International Conference "Distributed Computing and Grid-technologies in Science and Education" (GRID 2018), Dubna, Moscow region, Russia, September 10 - 14, 2018


1. Introduction

The ATLAS experiment [1] at the Large Hadron Collider (LHC) records large amounts of experimental data, analysis of which requires equally large amounts of Monte Carlo simulated data.

The EventIndex [2] is a global catalogue of all ATLAS events in all processing stages. ATLAS events are stored in files grouped into datasets. They are identified by GUIDs (Globally Unique IDentifiers).

Event searching in the EventIndex can be done by various parameters:

• event identifiers (run/event numbers, trigger stream, luminosity block),

• trigger information (level 1 trigger (L1) and high level trigger (HLT)),

• references (pointers) to the events at each processing step in all permanent files on storage.

The Trigger Database library (EITrigDB) is used for trigger information importing, decoding and access in the EventIndex. It retrieves the data from different trigger databases and stores in the HBase [3]. Apache HBase is an open-source, distributed, versioned, non-relational database. HBase provides Bigtable-like capabilities on top of Hadoop and HDFS. This library is written in Java. The EITrigDB core class is used by the ATLAS EventIndex core package (Atlas-Event-Index-Core) [4].

This article describes the trigger information and its handling with EITrigDB library.

2. The trigger information dataflow

The ATLAS trigger system had three selection levels during Run 1: Level-1 (implemented in specialized hardware), Level-2 (software-based analysis of information within the “regions of interest”

(RoI) marked by Level-1) and the Event Filter (software-based analysis of the full event). For Run 2 the software-based triggers have been merged into a single unit: the High-Level Trigger (see Figure 1).

Figure 1. The Trigger-DAQ System (Thilo Pauli, CERN)

Trigger decisions are stored in data files as trigger masks encoded using the B64 algorithm. If a bit of the mask is set, this means that one of the sets of trigger conditions (trigger chains) has been passed in this event. The position of this bit in mask (chain counter) indicates which chain has been passed. Depending on the trigger configuration, the same chain counter may correspond to a different chain name. The relation is uniquely defined by the trigger table corresponding to the trigger key (or Super Master Key - SMK). Trigger masks from event record are decoded, and chain counters are converted to chain names. The list of trigger chain names obtained after decoding are then stored in


Proceedings of the VIII International Conference "Distributed Computing and Grid-technologies in Science and Education" (GRID 2018), Dubna, Moscow region, Russia, September 10 - 14, 2018

106 updated event records. The COMA (COnditions MetadatA) [5] database in Oracle contains all trigger information for recorded data. The EventIndex uses trigger tables replicated from COMA to HBase by EITrigDB library for the trigger decision decoding. The trigger tables use SMK as key and ChainName:ChainCounter pairs as columns. If the SMK is absent in the event record it is possible to obtain it from the run number that is a part of the event ID. For this purpose Run:SMK table is replicated in the HBase from COMA. The trigger decoding data flow is presented in Figure 2.

Figure 2. Trigger information decoding

The dataset trigger overlaps show how many events satisfy the different trigger conditions (more than one trigger chains are passed). The trigger overlaps on the Hadoop Data Browser Web page [6] is an example how the trigger information is used for the trigger menu efficiency investigation. The information can be presented as a table or in form of a graph.

3. The EITrigDB library update

The previous version of the EITrigDB had no simulated Monte Carlo (MC) data support. Our task was to make the EITrigDB work with the MC data. The main goals in the update were:

 add trigger information support for the MC data,

 keep the library structure the same as in the previous version.

The COMA database does not contain trigger information for the MC data. This information is stored in the Monte Carlo Trigger DB (TRIGGERDBMC). ATLAS Offline Release [7] contains a package TrigConfigSvc reading the trigger chain table. It has two versions, in C++ and in Python. The MC Trigger DB parameters (SQL query and connection parameters) are used in the EITrigDB Java code.

As in the case of recorded data, sometimes the SMK can be absent in the event record. But in this case it is not possible to use the run number (this parameter is called MC channel number in the MC datasets) because the SMK does not depend on this parameter. The trigger information appears in the MC data at the reconstruction level. That is why the SMK number can be restored using the reconstruction tag (r-tag). The r-tags are a part of the event ID, like a run number.

ATLAS Metadata Interface (AMI) [7] contains the r-tags and the information about SMK.

AMI has a Web interface which can be used to browse the r-tags [8]. The Python AMI client is used to retrieve the table r-tag – SMK from AMI. This client is a part of the pyAMI package. EITrigDB calls the Python methods from Java. The r-tags corresponding to the reconstruction production step (production step = "recon") contain SMKs (see Table 1).


Proceedings of the VIII International Conference "Distributed Computing and Grid-technologies in Science and Education" (GRID 2018), Dubna, Moscow region, Russia, September 10 - 14, 2018

107 Table 1: R-tags and SMK r-tag productionStep SMK SMK stored in HBase

r10517 recon 2203 2203

r10210 merge absent -1

All SMKs are stored in the HBase. If a r-tag has no SMK than the DB returns -1 instead of positive-only SMK.

New classes were added in the EITrigDB library for MC data. They have suffix MC:

EITrigDB -> EITrigDBMC (storing and retrieving the data in/from HBase) EITrigDBig -> EITrigDBigMC (obtaining the data from MC TriggerDB, AMI)

The added classes inherit large part of methods form the classes for the recorded data. To save the same library structure, the methods which read the data from the databases are rewritten retaining the same names. R-tags are stored in the HBase without prefix “r” (the number only). This makes it possible to work with them like with run numbers in case of the recorded data. Some new methods were added in the EITrigDBigMC class. They retrieve the SMK for a given event ID from AMI and from HBase.

4. Conclusion

The new realization of the EITrigDB library has the simulated Monte Carlo data support. It has practically the same API as in the first version. As a next step it is possible to use Java AMI client instead of the external pyAMI package.

5. Acknowledgements

We would like to thank our colleagues: Joerg Stelzer and William Panduro Vazquez for their assistance and help in this work.


[1] ATLAS Collaboration, The ATLAS Experiment at the CERN Large Hadron Collider, JINST 3 S08003 doi:10.1088/1748-0221/3/08/S08003, 2008.

[2] Barberis D et al, The ATLAS EventIndex: architecture, design choices, deployment and first operation experience, J. Phys.: Conf. Ser. 664 042003, doi:10.1088/1742-235 6596/664/4/042003, 2015.

[3] HBase home page: https://hbase.apache.org

[4] D.Barberis et al., The ATLAS Event Index: The Architecture of the Core Engine, 18th International Workshop on Advanced Computing and Analysis Techniques in Physics Research, Seattle, WA, USA, 21 - 25 Aug 2017, https://cds.cern.ch/record/2291669/

[5] E.J.Gallas et al., Conditions and configuration metadata for the ATLAS experiment, J. Phys. Conf.

Ser., 396 052033 doi:10.1088/1742-6596/396/5/052033, 2012.

[6] F. Prokoshin et al., ATLAS EventIndex a catalog of physics data // EventIndex Workshop, 4-5 June 2018, Milan, p. 13-20, https://indico.cern.ch/event/708832/sessions/277733/

[7] Albrand S. et al., The ATLAS metadata interface, J. Phys. Conf. Ser. 219 042030, doi:10.1088/1742-6596/219/4/042030, 2010.

[8] J Fulachier et al, ATLAS Metadata Interface (AMI), a generic metadata framework, 2017, J. Phys.:

Conf. Ser. 898 062001, http://inspirehep.net/record/1638497


Documents relatifs

This selects an unbiased sample of probe muon candidates used to measure the efficiency, defined as the fraction of offline reconstructed muon candidates passing several stages of

The ATLAS trigger system [2] is a two level system consisting of a hardware based level-1 (L1) system, and a software based high level trigger (HLT), and can be seen schematically

The Front-End LInk eXchange (FELIX) will use the GBT protocol over optical links and transceivers to route data and commands (including TTC) between electronics on

improve the online muon identification in order to identify and reject fake muons and thus reduce the L1 trigger rate. A schematic diagram of the improved trigger algorithm for

Fast algorithms are executed using calorimeter and ID information within the RoI to perform the initial selection and identification of the electron and photon

like this would require a robotic system with a rotating actuator that provides an infinite acceleration to start and stop the needle rotation without generating transient

In an attempt to gain insight into synergistic neurite outgrowth, PC12 cells were treated with one of three combinations: pituitary adenylate cyclase-activating peptide (PACAP)

On behalf of the ATLAS Trigger/DAQ High Level Trigger Group?. Université de

14 The trigger performance for primary vertices in the b-jet sig- natures for 55, 110 and 260 GeV jet triggers; a the vertexing efficiency as a function of the number of offline

The trigger performance is defined in terms of specific metrics, comparing offline and trigger reconstructed jets, such as jet selection efficiency, and the transverse energy or

We observed regression of mutualism due to the proportion of mutualistic symbionts decreasing from 20% to less than 5% (see Figure A3a) and e)). We observed that the regression

The internalization and translocation from endothelial (human primary endothelial cells HUVEC) to cancer cells (human tumor cell line HCT-116) was studied in con- ventional

(i) the resistivity of woody roots samples was higher than that of a silty soil; (ii) the root polarized at frequencies lower than that of the soil; (iii)

By calibrating the scaled functional response that rules the ingestion of food and using average temperature conditions experienced by wild seabass (obtained from tagged

The 16 Regional trigger decisions are finally gathered by one unique board, the Global board, which communicates the dimuon trigger decision to the ALICE Central Trigger

Used in coincidence, it provides a fast identification of electron, photon and hadron and play an important role for the first level trigger for LHCb. In addition, the

The trigger eciency has been calculated with an almost complete simulation of the set-up, including the trigger detector segmentation and the treatment of the information by the

z Pipe-line operation, synchronous, fixed latency : 4 µs z Reduce the rate to 10 6 events per second. „ Level-1 : Software analysis on part of the data z Reduced and packed data

5 shows the performance of a single L2P as the inverse of the LVL1 accept rate sustained versus the number of worker threads.. In this measurement, the RoI has a fixed size of

If an event is accepted by LVL2, details of the processing at this trigger level, the LVL2 Result, is appended to the event stream and used by the Event Filter to proceed with

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

The prime motivation is to gain access in a uni- form and rapid way to event data from subdetectors which do not participate in the Level-1 trigger decision (e.g., event data from

ATLAS relies on a three-level trigger system to perform the selection: a very fast, coarse granularity, hard- ware-based LVL1 trigger which reduces the event rate to 75 kHz followed