D. Menasce, M. Rovere
I.N.F.N. Milano-Bicocca
I’ve been pondering about DB data use –cases recently and came up with the following:
We are approaching the day when we will be requested to initialize the detector for reading out physics
data: by then we need to load the detector with a configuration, encompassing the WHOLE detector,
addressed by a single and unique Key.
The problem is that we are accustomed, at least so far, to calibrate the detector by HC (sectors for the
barrel?). Each calibration is then stored and accessed by it’s own unique configuration Key: we need to
establish a mechanism to build a single configuration starting from a subset (variable in length) of such
partial configurations.
How we do this has big effects on how we design and implement the DB backend.
In the following I will try my best to explore various scenarios: this is work in progress, so this is neither
rigorous nor definitive.
Partial Configurations: a Puzzle
2
Consider the following use-case:
• we calibrate the detector in several steps: in each step we address only a subset of the whole detector
(this is described by the calib.dat KOC with a possible mismatch with detconfig). For e.g. we decide to
determine the best set of DAC values to initialize ROCs.
• after a few days work we have a collection of partial data, each named with its own unique configuration
key
2354
2355
....
2361
3 detconfig
3 detconfig
3 detconfig
3 detconfig
4 nametranslation
4 nametranslation
4 nametranslation
4 nametranslation
6 dac
8 dac
9 dac
12 dac
0 trim
0 trim
0 trim
0 trim
8 mask
8 mask
8 mask
8 mask
… .....
… .....
… .....
… .....
1 calib.dat
2 calib.dat
3 calib.dat
9 calib.dat
In principle there might be overlaps of DAC values of configuration 2354 and 2355 (for example a couple of
blades in 2355 were already present in 2354). Which of the two will be considered the valid data?
Should we avoid to make such kind of overlaps? How do we eventually enforce this to avoid ambiguites?
(there is no automatic check I’m aware of in POS, but I might be wrong on this)
Partial Configurations: a Puzzle
3
• now we need to start a physics run: we have to initialize the detector with a configuration that
encompasses all the partial ones we have set aside so far. In order to do this we have several
possibilities:
 we create a new configuration key by linking non-overlapping data of already existing ones
2354
2355
....
2361
3 detconfig
3 detconfig
3 detconfig
3 detconfig
4 nametranslation
4 nametranslation
4 nametranslation
4 nametranslation
6 dac
8 dac
9 dac
12 dac
0 trim
0 trim
0 trim
0 trim
8 mask
8 mask
8 mask
8 mask
… .....
… .....
… .....
… .....
1 calib.dat
2 calib.dat
3 calib.dat
9 calib.dat
3465
3 detconfig
4 nametranslation
dac
0 trim
This is the configuration of the WHOLE detector that
will be used to initialize for a Physics run
8 mask
… .....
calib.dat
Partial Configurations: a Puzzle
How can we implement this behavior
with the existing DB schema?
By using sub-versioning? And, more
important, how do we keep backward
compatibility with the file-based
configurations?
4
Problems with this approach:
• Who takes care of this task? An appropriate C++ program, an ORACLE procedure or something else?
• What is the input for such a procedure? User should prescribe the list of configuration sources and
what to do in case of overlapping data (different data corresponding to the same ROCs)
• Can this be fully automated (I doubt it…) or do we need a GUI?
Another possible approach to produce a complete configuration for detector initialization is the following:
• we begin with the usual, partial, calibrations and end up with a long list of resulting configurations
• once the detector is understood and under control, we run one single, final calibration over the WHOLE
detector and produce the necessary single and unique configuration valid for initialization.
This second approach requires less bookkeeping and machinery than the previous one but it is also
significantly less flexible.
Whatever the case, we still have to explore the concept of versioning of partial data in the DB to the goal
of building new configurations from already existing ones. This has a BIG impact both on the schema (is the
existing one flexible enough to accommodate such a requirement? I believe so…) and on the development
of the needed procedures to accomplish the task. Very BIG issue is also backward compatibility with files!
Partial Configurations: a Puzzle
5
We still have no definitive answers and are exploring these use-cases at best we can.
Again, we need to work closely with both POS and DB developers before the final DB schema
is deployed and before we implement our XML writing mechanism accordingly.
To this extent we will be at CERN starting Monday, July 7th (to be agreed upon).
I really urge people involved to be there together in order to solve this riddle, so that we can
proceed to implement the last major missing component in Debbie.
If we screw up this last component we might
create our own trap.
Partial Configurations: a Puzzle
6