Home
The fundamental function of the calibration database is to serve the various sets of calibration constants necessary to reconstruct data from a particle physics detector with multiple quasi-independent sub-detectors. Each sub-detector will have its own unique needs for the form and function of constants. These constants will change as a function of run number, and the run number boundaries between changes in the constants will be different for different sub-detectors. In addition the procedure for obtaining the constants may change over the life of the experiment; the definition of "the best constants" for a given run will be a function of time. These points in time when new constants supersede old will also vary for different sub-detectors.
Let's take a simple example of calibration data, say "target position," which is defined by three coordinates x, y, z, each represented by floating point number.
Using C++ as an example language, if a user asks for "target position":
auto data = calibration->GetCalib("/target/position");the calibration database should provide the appropriate data in the current context so it can be used:
if (data["z"] > 30) ..."The current context" is the key phrase here, since the values of target position could be different for different runs, values may change with time, e.g., if more precise calibration is performed. Also, a user may want to use a personal version of data for various reasons.
The picture above illustrates features of CCDB that involve control of the context:
- The data returned depends on run number.
- A history mechanism: by default CCDB honors the last assignment of data to a particular run, but one can always recover assignments made in the past.
- Variations (equivalent to "branches" in version control systems): users have the ability to create and work with alternative versions of the data, varying the run assignments and/or the data itself.
Data is associated by the namepath. The namepath string is unique across all detector systems. Forward slash(/) is used to specify a hierarchical namepath.
For example:
/target/position
/FDC/driftvelocity/timewalk_parameters
/FDC/base_time_offset
This allows implementors of individual detector systems to specify a hierarchy with as much or little depth as is needed, appropriate to the physical structure of their device.
Namepath format: Allowed symbols are a-z, A-Z, 0-9, '_' and '-'. Spaces or other special symbols are not allowed in the namepath (this simplifies console management and database validation of namepath objects).
/My-path/to/data_01 # OK
/Some...thing/is wrong here! # ERROR: illegal symbols '...', '!' and spaces.
Each namepath corresponds to a "table type". Table type * - defines columns and a number of rows. The idea behind of "type table" is that while data values may change, "the shape" of the table never does.
The term "table" is ambiguous when talking about data, and it is especially ambiguous when topic is related to databases. Thus CCDB uses the term "table type" for a definition of data (the shape), and "data set" or "constant set" for the data itself, i.g. values of table type.
In the example with target position, the namepath "/target/position" is a table type, defining data arranged in three columns of type "float" and one row. Whatever the values of /target/position are, they are always presented as one row of "x", "y", "z".
Each column has a type and may have a name. However column names are optional.
The "/target/position" example has 3 columns named "x", "y", and "z". They could be also identified as 0, 1, 2.
As another example, the /FDC/driftvelocity/timewalk_parameters parameters may have members
"slope", "offset", and "exponent".
By contrast, a set of constants with a namepath "/FDC/CathodeStrips/pedestals" may have 100 values identified simply as 0, 1, 2, 3, ...
Column types - Column types may be one of the following:
- int
- uint
- long
- ulong
- bool
- double
- string
Each table type may have multiple versions of constant sets, i.e. the data. Each constant set has at least one "assignment". The assignment holds the information specifying the association of the constant set with a context:
- run range - Runs for which the data is valid
- creation time - Creation time of the assignment (used for the history feature)
- variation - Name of the variation
- comment - Any useful comments about the assignment
One could say that assignment shows the context within which the data "is correct". One could also say that while a constant set is data, an associated assignment is a header for this data.
A particular constant set can have several assignments. This allows the use the same constants for different run ranges and helps avoid "update anomalies."
