Food for Thought

1. Calibration files directory structure:
   • where to put the files
   • how to describe file path names in the metadata database (data_ident field)
   • how to access the calibration files

   This has been covered most recently in the document Calibration Files Directory Structure. We're talking specifically about production files at SLAC. Test or development files, or files at other sites, need not be organized this way, but it is recommended for any substantial collection of files. That is, such a collection should have a single root, with subdirectories named after subsystems. There should preferably be a site-wide variable defined in a group set-up file for this root. The organization within the subdirectories is up to the subsystems (but they should take care that file names are unique). In this way, it is easy to port the whole thing to another site.

2. Valid instrument names and flavors:

   For this one see Calibration Flavors and Instrument Names.

3. Using timestamps consistently in the metadata:

   This is perhaps not an urgent matter just now, but the way things stand is confusing. Some timestamps entered in the metadata are in local time (local for the MySQL server, that is), others are GMT, others are up to the user. The proposal is to use GMT everywhere, in particular in the fields enter_time, update_time, and in the user fields vstart, vend, input_start and input_end. Of these, only vstart is crucial for now.

   Tools for registering calibrations (rdbGUI and a routine in the calibUtil package called registerCalib) can, without too much work, be made to insure that enter_time and update_time are handled correctly, and some aid can be provided in both environments to help users translate from local time to GMT.

4. Validation procedures of the calibrations:

   Only the subsystems can determine what constitutes an adequate evaluation of a calibration, a discussion which is outside the scope of this meeting. However the calibration infrastructure provided by SAS has to allow for tracking of calibrations in different states of acceptance and has to provide foolproof procedures to change from one state to another.

5. Tkr split points and Cal LAC thresholds:

   Is the calibration database the right place to store things like Tkr_splits and LAC_thresholds? Or would a new db - conditions db - be better? Are there other objects we know of that will appear later? What's the usage of these objects?