The results on the development of complex databases for the CBM experiment are presented. The set of basic structural characteristics of the required databases is provided. It is based on the analysis of databases used for data processing in high-energy physics experiments. The complex includes the following databases: Configuration DB, Condition DB, Geometry DB, TagEvent DB and Component DB. The description of the component database (Component DB) is given. The main principles of the functioning of the geometric database (Geometry DB) are considered.
The CBM (Compressed Baryonic Matter) experimental facility that is being built at GSI (Darmstadt, Germany) at the accelerator complex of antiprotons and heavy ions FAIR (Facility for Antiproton and Ion Research) is intended for studying the properties of superdense baryonic matter generating in 8-45 GeV/nucleon proton-nuclear and nucleus-nucleus collisions [Friman, 2011].
Figure 1 presents a dielectron version of the CBM installation intended for research on shortliving vector mesons and charmonium decaying into an electron-positron pair.
Inside the dipole magnet there is a target and a coordinate tracking system STS (Silicon Tracking System) containing 8 stations of 300 mkm two-way strip detectors. Together with the dipole magnet, STS is used to reconstruct charged particle trajectories and to determine their momenta. The Cherenkov detector RICH (Ring Imaging Cherenkov) and the Transition Radiation Detector (TRD) should provide a reliable registration of electrons/positrons with the pulses of more than 1 GeV/s. The time-of-light detector (TOF) constructed on the basis of Resistive Plate Chambers (RPC) is intended for hadron identification in a wide energy range. The Electromagnetic Calorimeter (ECAL) is used for electron/photon identification. The Projectile Spectator Detector (PSD) is intended for the reaction plane determination.
Due to high beam intensity and high multiplicity of secondary particles, huge data is expected to be accumulated by the DAQ (Data acquisition) system for further analysis.
At the current moment the CBM collaboration moves from the stage of prototypes research and tests to detectors and their components production. The high level of control for manufacturing process is required because of the complexity and high price of the detector components.
As a result, there is a need for development of a database complex for the CBM experiment. This
paper presents a complex of Database Management Systems (DBMS) for the CBM collaboration and
describes a current status of its implementation. DBMS structure was designed based on the
experience of using databases at the LHC and other experiments in high-energy physics [
In the CBM databases the following data should be supported: detector production and installation, survey data, event data and metadata, detector geometry, online configuration, run conditions DCS (Distributed Control System) and others, online calibrations and alignments data.
Below we present the list of main databases together with their brief description.
Configuration database: to store a large number of parameters describing the topology of the DAQ system, hardware and software components and run parameters. It only stores the parameters that are directly required to start and support in efficient operating conditions of all elements of DAQ system.
Conditions database: to store, retrieve and manipulate condition, alignment and calibration data. Condition data keep the state of the CBM setup at the time when events are collected. A subset of the data will be used both for online (FLES [Hutter,2015]) and offline computing.
Tag Event database: to store, retrieve and manipulate event data and corresponding metadata from all stages of data processing (Raw, Event Summary Data, Analysis Object Data, etc.).
Geometry database: to store, retrieve, manipulate and load the detector geometry that is stored as a set of well tested and versioned detectors geometry in a view of ROOT files and metadata.
Component database: to manage properties of detectors and electronic components obtained in QA (Quality Assurance) process after mass fabrication. Component database includes mechanical/engineering production data and electronics data (calibrations, chip thresholds etc) which are kept separately in general.
Most of the databases should be implemented as relational databases. The exclusion is the
Configuration DB. It stores different types of data as hardware description, software description including
programs with their run parameters etc. There should be a possibility to change data in easy and
convenient way as such procedure is frequent one. The possible solution for Configuration DB is to use
the object oriented database such as in the ATLAS experiment [
The Component Database (DB) is the first database that was designed and implemented as a part
of the CBM databases project [
The DBMS PostgreSQL v8.4.20 [PostgreSQL group] was used for implementation of Component DB. Basic services are supported for each CBM detector via WEB access to data bases: data viewing of detector components, search in navigation mode, inserting and editing components data, support of the catalogs, authorization services for system access. The authorization is based on affiliation to the detector’s group.
The implementation is realized on the basis of client-server interaction. The same schema for all detectors was produced. Scripts and their usage in according html-pages were implemented. Figure 2 presents an example of the Magnet main page.
The database structures for several detector systems (magnet, STS, MVD) were confirmed with
the responsible persons. Currently, the Component DB includes eleven tables, six of which are the
catalogs [
The Geometry Database is designed and implemented as a part of the CBM Databases project
according to the User Requirements Document (URD) [
The basic notations are defined in the URD. According the URD a geometry module is defined as some metadata and a file in ROOT format with content of detector geometry. Metadata includes module name, unique module index and other data. Geometry module linked with transformation matrix is the module setup. Complex of setup modules which represents the full CBM geometry is defined as setup.
Currently, the geometry ROOT files are stored and distributed through the CBM software repository. Setups as combinations of geometry files are defined on the ROOT macro level. Such a situation is rather complicated, error-prone and, thus, not ideal. Moreover, handling by the software repository does not match the requirement that a given geometry version must not change in time. The distribution of the module geometries as well as entire setups through a database thus appears as desirable solution.
The Geometry DB will store the CBM geometry and setup modules as well as setups as combination of setup modules. It provides appropriate interfaces to view, retrieve and update setup modules and setups. The URD also characterizes three categories of users of the Geometry DB: CBM user, Developer, and Lead Developer. The basic use cases for those categories are Load Geometry, Download Geometry, WEB View, Add Geometry, Add Setup Module, and Add Setup, the detailed description of which is in progress.
The prototype of the Geometry DB is implemented. It includes two parts: server and client. Server part is used to view and edit setup and its content. Figure 3 shows a content page of the Geometry DB for a specific setup. Client part is used for loading the geometry into memory, for simulation and reconstruction. It also includes the ROOT macros to load the setup by a tag.
The complex of databases is an important part of the software for the CBM experiment. The set of databases is defined and two first databases were designed and implemented. The Component DB stores all data on the CBM construction and it will be used intensively during CBM commissioning. Though the database is ready for use it is supposed that it will be upgraded on the base of experience of its usage. The Geometry DB has benefits both for employees and top management already in the current stage. This is a transparency and usability, reduced geometry loading code, business transparency, and advantages in monitoring of geometry. The beta version of the Geometry DB is ready for use. Friman B. et al. Compressed Baryonic Matter in Laboratory Experiments // The CBM Physics Book— 2011.
Hutter D. et al. CBM FLES input interface developments // CBM Progress Report 2014— 2015— p.101.
PostgreSQL group PostgreSQL Documentation // (https://www.postgresql.org/docs/manuals/) S. Agostinelli et al., Geant4—a simulation toolkit // Nuclear Instruments and Methods A 506 (2003) 250-303.