Using the following simple (already known to be too simple, in fact) procedure for determining calorimeter pedestals as a model:
Start with raw data from a single run. Throw out all events with more than 2 tracker hits. For each adc (80 logs * 2 ends * 4 gain ranges) find its average reading over the remaining events. This is the pedestal.
...one might describe output from a calibration procedure in general as consisting of two pieces: the globally-descriptive part and per channel (or other index) information.
| Global |
| - version number for output from this run |
| - version of software creating the data set |
| - description of uncut input (e.g., raw data from run xxx) |
| - description of cuts (e.g., #hits < 3) |
| - description of other parametrization for procedure (optional; probably wouldn't need this field for pedestals) |
| - description of input after cuts (e.g., #events kept) |
| - description of objects being calibrated, e.g. calorimeter adcs |
| - time range for which computed values are valid. |
| Per calibrated object |
| - the value or values (for pedestals, would just be a single floating point number, but in other cases will likely be a set of constants for a particular functional form) |
| - characterization of key associated with value (e.g., for pedestals this might be the gain range of the adc) May not be applicable or, even if applicable, may not be necessary if the information is readily available by other means |
| - quality-of-computation information (e.g., rms) |
Apparently relational databases, in particular MySQL, which is free, are all the rage within HEP for keeping track of this kind of information. I've taken a look at it and my first impression is yes, it would do the job.
Here is a provisional and probably naive hierarchical design for some tables, starting from the bottom.
A typical name for a pedestals table might be something like Calor_Ped_47
| ADC | Value | RMS |
| 0 | 195 | 2.3 |
| 1 | 203 | 3.1 |
| 2 | 195 | 3.1 |
and so forth.
At the next level up would be a table whose rows would correspond to individual calibrations of this type, call it just Calor_Ped
| ID | Soft | Input | MaxTrkHit | NEvt | VStart | VEnd |
| 44 | 1.0 | Raw300 | 2 |
10132 | 3/3/2000/10:17:23 | 3/3/2000/12:15:07 |
| 45 | 1.0 | Raw302 | 2 |
14705 | 3/3/2000/15:01:20 | 3/3/2000/17:21:48 |
At the top, yet another table whose rows correspond to types of calibration
| Name | Scope | RowKey | What else??? |
| Calor_Ped | Calorimeter | ADC | ? |
| Calor_CrystalMap | Calorimeter | Crystal | ? |
This is an alternative design, with some attention paid to efficiency and limiting need for privileged access. There would still be three table types, but only two levels in the hierarchy. The top-level table (Calibration Type Descriptors) would be as in Design A. The next level would encompass all calibrations of a given type (e.g., calorimeter pedestals) with two tables, call them the (Calorimeter Pedestal) Summary Table and the (Calorimeter Pedestal) Data Table. In each of the two a row of the table would correspond to a single calibration. The Summary Table would have only a few columns useful for looking up a particular calibration, similar to the Results Catalogue in Design A, but it would also include an index pointing to the relevant row of the Data Table. Each row of the Data Table would contain all the values in the Results Table of Design A.
Neither of these designs is likely to be precisely what is implemented. They are described here as some indication that a relational database could be used to store this data in a reasonably natural fashion.
Acces to a MySQL database is via a server. Presumably there is one central official database and anyone with network access can fetch data from it, but what about the itinerant laptop? MySQL can export query results to a file. The file could then be copied to the laptop's local disk and imported back into a little MySQL database living on the laptop.
MySQL does have means to control access so that, for example, most users would only be able to read from the central repository. Needs to be investigated further.
Should be possible to write appropriate converters so that Gaudi applications would have access to calibration data sets. Needs to be investigated further.