MOOT and Offline

MOOT will be the gateway for offline jobs both to traditional offline calibrations and to configuration information

Offline calibrations

Now: The calibrations themselves are normally (by convention, not because of any hard requirement) kept at SLAC on disk in a well-known area. The root of the directory where they are kept is identified by the environment variable LATCalibRoot (currently this directory is /afs/slac/g/glast/ground/releases/calibration). The files can be made available elsewhere transparently simply by copying the file hierarchy and setting LATCalibRoot to an appropriate value. To be used by offline jobs, files must be registered in the Calibration Metadata Database. Typically this is done interactively with rdbGUI.

Hereafter: In the MOOT era, calibration files will be maintained by MOOT. The functions of the Calibration Metadata Database (which consists of one MySQL table) will be taken over by the table Offline_Calib in MOOT's database. In addition, as part of the registration process MOOT will copy the files to its archive. Ideally, two ways to register a new file will be provided:

1. A variant of rdbGUI for interactive use
2. Via script: C++ functions which can be invoked from python (or from C++, but this is less likely to be useful).

There will be some changes in the protocol for accessing the calibrations from an offline job. They are not large and won't involve much work either for calibration infrastructure or for users, but they will not be backwards-compatible. When the change-over is made and new calibration files are registered with MOOT, calibration infrastructure and user set-up will have to change as well. Files already in the old system can be re-registered with MOOT, so that new code will be able to access old calibrations. In order to ease the transition further, files could be registered in both systems for a while.

Configuration

Some parts of LATC configuration (e.g., tracker splits) are of interest to Offline jobs. Just as for calibrations, one needs to find that version of the information which is appropriate for a particular event; that is, to find the configuration in effect at the time the event was taken. In principal, this can be determined from the key (aka fmx logical id) of the LATC master file in use at the time. This key is part of the context information in the data stream and gets stored in the TDS with every event (see lsfDataStore package, especially lsfDataStore/lsfDataStore/LsfConfiguration.h, (or maybe lsfData, especially lsfData/lsfData/LsfConfiguration.h) and LdfEvent package, particularly LdfEvent/LdfEvent/LsfConfiguration.h) so we can perhaps do something like this:

• There is already a mechanism within CalibDataSvc for keeping track of the timestamp of the current event in order to compare it with validity intervals of calibration. It can be expanded to also update a local copy of the LATC master file key and compare to old value.
• If values differ, CalibDataSvc can ask MOOT for keys (MOOT ids in this case) and types of the files the LATC master refers to (CalibDataSvc will have cached previous list).
• Only some of them will be of interest to Gleam processes. If an application asks for a file of a type whose key has changed, infrastructure will know the new file has to be fetched.

This will likely involve adding another conversion service to CalibSvc for config files to — sort of — play the role MySQLCnvSvc plays for calibrations, as well as the usual sorts of changes and additions needed for each new (calibration or configuration) type.

Created: 15 June 2006 Last revised: Friday, 19-Jan-2007 15:16:37 PST

J. Bogart