Calibrations and Where to Find Them

Background

Currently new calibrations are registered in the Calibration Metadata Database. One of the fields, data_ident, is the path to the file. As is evident from the rdbGUI screen shot, the path typically contains a reference to an environment variable LATCalibRoot, but not always. It can and sometimes does include other environment variables or none at all. The calibration infrastructure code (CalibSvc package) has no special knowledge of LATCalibRoot; it is merely translated, just like any other environment variable.

We recommend that the official copy of real calibrations to be used with real data (the rules for those concocted for MC are a little looser) be kept at SLAC in the space dedicated to that purpose: /nfs/slac/g/glast/calibrations, and that the standard SLAC site definition for LATCalibRoot be this directory. Such calibrations should be registered in the Metadata Database with a path starting with $(LATCalibRoot). It then is possible for other sites to pick up the full set of production calibrations and, if LATCalibRoot is defined to be the root of the copied hierarchy, CalibSvc will be able to find calibrations in the same manner, regardless of where it's running

Toby's proposal

I think it was: recommend that the definition of LATCalibRoot bear a simple relation to the definition of GLAST_EXT. If calibration infrastructure determines that LATCalibRoot is undefined, it should operate as if it had this default definition.

Note that at SLAC there is no such relation, but it isn't necessary, either, since users there usually do have LATCalibRoot properly defined.

Why not?

There are several reasons why I think the gain to be realized from a default definition of LATCalibRoot is not worth the trouble. More or less in order of increasing importance, they are:

• It requires changes to CalibSvc The code needed is not especially extensive or complex, but it's basically a hack. Nothing else in the calibration infrastructure is remotely similar.
• It's not a big deal for users to define another environment variable. Surely it's a lot less trouble than getting the files copied promptly and reliably to a remote location! I suspect the problem all along has been lack of awareness of what is needed since for a long time most users and developers had no contact with real data. My preferred solution is better documentation: the procedure for creating the LATCalibRoot environment variable and an explanation of its purpose ought to be documented in a suitably prominent place; e.g. for Windows it could immediately follow the discussion of GLAST_EXT on this workbook page.
• LATCalibRoot will most likely become defunct once MOOT gets going. Currently there is no single entity responsible for calibration files. Subsystems put them in a place deemed to be convenient (usually somewhere under /nfs/slac/g/glast/calibrations) and the calibration code in Gleam happily reads them wherever they happen to be, as long as they're properly registered in the database. In the new world, MOOT will own calibration files as well as configuration files in the following sense: all such files will be registered with MOOT, and at that time MOOT will copy them to an archive. The archive location is the one MOOT will store, and hence the one clients like Gleam will use. Furthermore, the stored path will always be relative: relative to MOOT's archive. There is sure to be an environment variable involved somehow, but it might have a somewhat different function than LATCalibRoot has now.

J. Bogart, Last Modified: 01-Jun-2010 15:46:21 -0700