Abstract

In LHC Run 3 the ALICE Collaboration will have to cope with an increase of lead-lead collision data of two orders of magnitude compared to the Run 1 and 2 data-taking periods. The Online-Offline (O2) software framework has been developed to allow for distributed and efficient processing of this unprecedented amount of data. Its design, which is based on a message-passing back end, required the development of a dedicated Analysis Framework that uses the columnar data format provided by Apache Arrow. The O2 Analysis Framework provides a user-friendly high-level interface and hides the complexity of the underlying distributed framework. It allows the users to access and manipulate the data in the new format both in the traditional “event loop” and a declarative approach using bulk processing operations based on Arrow’s Gandiva sub-project. Building on the well-tested system of analysis trains developed by ALICE in Run 1 and 2, the AliHyperloop infrastructure is being developed. It provides a fast and intuitive user interface for running demanding analysis workflows in the GRID environment and on the dedicated Analysis Facility. In this document, we report on the current state and ongoing developments of the Analysis Framework and of AliHyperloop, highlighting the design choices and the benefits of the new system.

Highlights

  • ALICE in Run 3 will run in so-called continuous data-taking mode, with the unit of information being a snapshot of data in a 10 ms-long time window, dubbed timeframe

  • In order to fully exploit the potential of the Data Processing Layer (DPL) for physics analyses, additional developments were required, resulting in the creation of the Analysis Framework as an extension of the DPL

  • The system, called AliHyperloop, can benchmark each analysis in terms of functionality and resource consumption and compose trains that are later submitted to the GRID or a dedicated Analysis Facility - a specialized Grid site with CPU and disk resources adjusted for analysis needs and small fraction of data pre-staged locally

Read more

Summary

Core design

The analysis data model in Run 3 is a collection of flat tables, arranged in a relational database-like structure using index connections. The particular data processors, known as tasks for similarity with the previous analysis framework, are created by the end users and provide a C++ structure with conventionally defined callbacks and declarations of inputs/outputs. By relying on pre-defined index, to access parts of the grouped table (for example the track information table) that correspond to certain rows in the grouping table (for example the collisions table). This is possible for any tables, related by index, if the index column of the table is sorted. The webbased analysis tools automatically adds service tasks at certain stages, that provide certain common information like particle identification (PID) decisions or track selection flags, when deploying a workflow

Bulk operations and declarative analysis features
Future developments and conclusions
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.