OpenIntervals

Introduction

As explained more in ConditionsData, the standard conditions database has "closed intervals". When a calibration is assigned to run range, the range must have a beginning and an end. If an executable attempts to retrieve calibrations outside the known intervals, the job throws an error. This style require careful maintenance, but allows precise control and reproducibility of conditions. This is the only style allowed in collaboration production campaigns.

The "open intervals" style reduces the reproducibility but is simpler to maintain. In this style, calibrations are typically assigned an open run range. The interval starts from a given run when the calibration was created, but there is no end to the interval. Requests for calibrations for future runs will be matched to last open interval. At some point in the future a new calibration is created, a new open interval is added, and this calibration takes over as the valid content for future runs. The order that calibrations are stored to the database is important because the later entry (containing the requested run) overrides the earlier entry. If a patch is required, it is added with a start and end declaring the patch period. Since this is the last entry, it takes precedence for the patch period.

Example

In the displayed example, each "CID" represents a "calibration identifier" which contains on instance of calibration content. Run number passes to the right and time passed down the chart. The first row (CID0,1,2) represent the simplest case - when CID0 was inserted, it was the only calibration and represented all runs. When CID1 was committed, it takes over from its start run to the future, then CID2 similarly took over the future at some point. The rest represent patches which supersede the original set for different intervals. The red boxes indicate the algorithm choice for the calibration content. CID10 being the latest open-ended interval will be the choice for future runs.

Code recipes

Calibration content to be committed needs to be prepared in the same way as standard content. The table must be declared in code, created using SQL, and defined with a TID. Since this part is the same, this table can also be used in a standard conditions set, with closed intervals and purpose/version. The open interval IoV's are kept separate from the closed interval IoV's. The content must be prepared in standard text format. When IoV's are referenced, they are in standard IoV format.

When you commit a calibration, you must know the initial interval. Setup Offline code as usual to access the tools. This example is an open-ended interval from run 105000 and on to the future.

openTool commit-calibration --file MyTable1.txt --iov 105000-MAX

This example is closed-interval patch

openTool commit-calibration --file MyTable2.txt --iov 105000-105100

To retrieve a calibration for a given run

openTool get-calibration --name MyTable -run 105005 > MyTable3.txt

To retrieve an open interval table in an art module, in the module header:

#include "Offline/Dbservice/inc/OpneHandle.hh"
OpenHandle<MyTable> _mytable_h;

In the beginSubrun:

 _mytable_h.update(subrun.run(),subrun.subRun());

In the module event processing

const MyTable& mytable = _mytable_h.table();