The ATLAS DAQ system online configurations database service challenge

Abstract

The ATLAS DAQ system online configurations database service challenge Igor.Soloviev@cern.chAbstract. This paper describes challenging requirements on the configuration service for the ATLAS experiment at CERN. It presents the status of the implementation and testing one year before the start of data taking, providing details of: the capabilities of underlying OKS object manager to store and to archive configuration descriptions, its user and programming interfaces; the organization of configuration descriptions for different types of data taking runs and combinations or participating sub-detectors; the scalable architecture to support simultaneous access to the service by thousands of processes during the online configuration stage of ATLAS; the experience with the usage of the configuration service during large scale tests, test beam, commissioning and technical runs. The paper also presents pro and contra of the chosen object-oriented implementation comparing with solutions based on pure relational database technologies, and explains why after several years of usage we continue with our approach. IntroductionThe configurations database service described in the paper is a part of the ATLAS High-Level Trigger, Data Acquisition (DAQ) and Controls system [1]. It is used to provide the overall description of the DAQ system and partial description of the trigger and detectors software and hardware. Such descriptions cover the control-oriented configuration of all ATLAS processes running during data taking (including information such as: which parts of the ATLAS systems and detectors are participating in a given run, when and where processes shall be started, what run-time environment to be created for each of them, how to check status of running processes and to recover run-time errors, when and in what order to shut down running processes, etc.) and provide configuration parameters for many of them (overall DAQ data-flow configuration, online monitoring configuration, connectivity and parameters for various DAQ, trigger and detector modules, chips and channels).

The ATLAS Data Acquisition and High Level Trigger system

“…The Configuration service [117] provides access to the overall configuration of the DAQ system and to a partial description of the trigger and of the ATLAS detectors, which is stored in the Configuration Database. This database contains all information, from command line parameters to a specification of the overall organization of both hardware and software, needed for running the DAQ software.…”

Configuration Information System for online processing and data monitoring in the NICA experiments

“…The developed Configuration Database (ConfigDb), which is one of the main parts of the Configuration Information System, stores both a set of various hardware configuration parameters, such as those required for setting the detectors of the experiment into operation modes, for instance, working voltage, and descriptions of a sequence of online software tasks (processes), including raw data digitization, online histogramming, fast event reconstruction and event monitoring, to be started and run in a predefined sequence, and controlled or stopped during experiment sessions. The possibility of partial use of the existing configuration systems [3] implemented in other particle collision experiments has been considered, however, in this case, a large amount of functionality would be redundant for the NICA experiments. As a result, it has been decided to develop its own system, but using the existing application programming interface (API) to control such online tasks.…”

Configuration and control of the ATLAS trigger and data acquisition

“…Finally, in order to be able to retrieve the configuration used for a specific run, we established a Run Number Service to assign a unique identifier to each run, and the OKS Archiver [14] that stores the configuration of each run into a relational database.…”

“…Furthermore, we developed and deployed IPC proxies on the multi-core machines in order to limit the number of TCP connections to be handled by the central services. We revised the configuration service [14] in all its parts: in particular, the database schema was optimized to reduce any information duplication and a hierarchical tree of Remote Database Servers was put in place to serve configuration data to all clients. Finally, even at the application and graphical interfaces layer we had to re-implement part of the software to deal with the augmented demand on scalability and performance.…”