Definitions & intent
Questions
Workarounds
Call interface

Considerations when registering calibrations

flavor and instrument: what do they mean?

My original expectation was that there would be a small number of different hardware configurations for prototype instruments, plus the real thing. The value for the instrument column in the metadata database would therefore be one of a small set of values like EM, LAT, CU,.. At that time I didn't envision large constituents, like a tracker or a tower, belonging to more than one instrument at different times; but even if I had, I would have assumed that, when the constituent was integrated into a new instrument, it would have to be recalibrated

• as a means to check whether anything got broken
• to see if channel response changed due to changes in temperature, humidity,...

Now it appears that, for at least some kinds of calibration, this isn't practical because of the length of time it takes to accumulate the necessary data. It may be the case that someone will want to use calibration data taken when a component was integrated into instrument A while analyzing data taken after the component has been integrated into instrument B. Because of the fluidity of the components, no scheme of assigning instrument values to calibrations will entirely honor the original intent. One possibility is to define different values for the instrument column for each configuration which is calibrated. I can think of two possible drawbacks:

1. Calibration infrastructure can only accomodate a single instrument in a particular run. You specify the instrument in job options, and the only calibrations which can be fetched are those whose metadata value for instrument matches the job options value.
2. There is no formal way to identify calibrations made on the same component if the component was integrated into different instruments.

Another possibility is to use the flavor column to distinguish the different hardware configurations. The concept of flavor has no semantics. Its use and meaning is totally up to the application, though the chief motivation was probably the requirement to provide a way to use different sets of constants in different circumstances (e.g., simulation and recon). The one big difference as far as calibration infrastructure code is concerned (not surprisingly, given the motivation) is that it is possible to access calibrations of different flavors within a single job. However, if different flavors are used to label calibrations of the same component in different incarnations, it is the case, as for 2. above, that there is no formal way to identify the calibrations as having any relation to each other.

Questions for calibration writers and readers

1. What are the different circumstances (hardware configuration, locale) for which you will do calibrations?
2. About how many calibrations of a given type (where type is short for the metadata quantity calib_type and refers to things like TKR_Splits, CAL_Asym, etc.) will you do in the same configuration (1, 2-10, more,..)?
3. Will several different types of calibration be done from input taken at the same or nearly the same time?
4. Do you intend to make calibrations in one hardware configuration (e.g., tracker-only instrument) and use them for recon of data taken in a different configuration (e.g., integrated tower)? If so, for which calibrations is this the case? Seems like it shouldn't be necessary for charge-injection calibrations.
5. Same question as previous, but for locale.

Workarounds

In the short term (and, relative to the life of the instrument, the integration phase is short term) I don't think it's worth it to write or modify a lot of code to deal with the not-so-discrete set of instruments. Instead we can play various tricks with the data files and metadata entries, such as

• Making a copy of a calibration file for a calibration made on a tower in a teststand, then editing the tower number when the tower is moved to its true position on the grid.
• Concatenating calibrations for different towers into a single file.
• Making two entries in the metadata database, both pointing to the same file (data_ident column), but with different values for other columns such as flavor or instrument.

Call interface for register

I'm about to implement the following method in the Metadata class of calibUtil:

    eRet registerCalib(const std::string& inst, 
                       const std::string flavor,
                       const std::string& calib_type,
                       const std::string& data_ident,
                       const std::string& data_format,
                       const facilities::Timestamp& vstart,
                       const facilities::Timestamp& vend,
                       const std::string& input_desc,
                       const std::string& notes,
                       const std::string& proc_level,
                       const std::string& locale,
                       const std::string& fmt_version = "",
                       const std::string& completion = "OK");

Any comments or suggestions? For example, are there sensible defaults for any more of the arguments? What other operations need to be C++ callable?

Last modified:
Joanne Bogart