DDCond Manual

1 Introduction

In a high energy physics experiment the data originating from particle collisions (so called $Event$-$data$) in most cases require supplementary, mostly environmental, calibration- or alignment data to extract the physics content from the recorded event data. These supplementary data are time-dependent and typically called $conditons$. The ability of an experiment to produce correct and timely results depends on the complete and efficient availability of needed conditions for each stage of data handling. This manual should introduce to the DDCond toolkit, which provides access to conditions data within the $DD4hep$ data structures [1].

The DDCond extensions to the $DD4hep$ toolkit formalize both the access and the management to time-dependent data necessary to process the event data. In this manual we will shortly describe the model used to organize and manage the conditions data internally and then describe the user interface to actually perform the required actions. These conditions data typically are stored in a database. Nearly every high energy physics experiment has strong feelings how to efficiently read and store the conditions data in terms of tablespace organization and data format. For this reason DDCond does not attempt to solve the persistency problem, but rather defines an interface used to load missing data items from the persistent medium. Any persistent data representation, which can fulfill the requirements of this interface may be adopted by the DDCond conditions caching and access mechanism.

At the end of this manual a walk-through of an example is discussed to illustrate, which steps have to be performed to use the $DD4hep$ conditions store within a client application.

1.1 Definition of Conditions Data

Conditions data are firstly

• raw data values. Raw data values are recorded from measurement devices such as thermometers, pressure devices or geometrical parameters resulting from survey parameters and others. These data may change with time, but have one and only one version.
• Secondly there is the large group of data derived from the raw values. These derived values are transformed from one or several raw values into new data items with an interval of validity being the intersection of the intervals of validity of its ingredients. Effectively every raw measurement requires calibration to represent a useful value. Hence, nearly all raw values require such a transformation. Since these data are re-calibrated, not only one version exists, but many e.g. as a result of different calibration algorithms.

Typically one data processing application predefines for all events to be processed the corresponding versions of the conditions data to be used. This time span typically is much larger than the intervals of validity of single data value. The collection of all individual data item version for such a large time interval is called a ”global tag”. Within such a global tag, several conditions values of the same data item, but with a different interval of validity may be accessed.

Given this definition it is evident that the division between raw values and derived conditions is rather fluent. Derived data as a result of a calibration process are technically identical to raw values in an analysis application using these re-calibrated constants. Hence, as soon as derived data enter the conditions database they are technically identical to raw values.

To support such calibration processes producing derived conditions data, DDCond provides a mechanism to project new values given a set of recipes provided by the user. This recipes can project a set of coherent new conditions for a given event time accordingly.

1.2 Conditions Slices

Conditions slices define a coherent set of conditions data valid for an event recorded at a specific time. Each of the individual conditions of the slice has a certain interval of validity, hence the validity of the entire slice is defined as the intersection of these validities. As a corollary, the slice may be valid for more than one event as long as the event’s time stamp is within this intersection. To maximize the flexibility, and to allow users to implement private slice implementations, slices have a common interface, the $ConditionsMap$ (See section 2.2). For most practical purposes and to share tools between slice implementations, this interface is sufficient.