Supporting a Calibration Type within the Gaudi Framework

Background

If you're new to the subject, please first see the Gaudi and Calibration Infrastructure page, particularly the opening section and the section on TCDS data.

Name it

Every calibration type has a string name. The name is used in the MySQL dbs and also as part of the path in the TCDS. Names are of the form subsys_specificType where subsys must be one of ACD, CAL, TKR or Test. Examples of existing names are

Under normal circumstances (except possibly for certain Test types) this is precisely the string that will appear in the calib_type column of the MySQL dbs. It also will appear as the second component of the TCDS path. Typical paths look like

That is, the path always has first component (root) = "Calib", second is calibration type, and third is the flavor.

Inform interested parties

The name has to be known to the CalibData::CalibModel class in order to form the path name. It also has to be equal to the value used for calib_type when the corresponding MySQL row was created. There are two ways to create this row. One allows arbitrary string values for several columns whose values may be logically viewed as of type enum. The other is more restrictive. It takes arguments of enumerated types for instrument name, calib_type, and several other fields. Any record inserted using this second method is guaranteed to be known to the calibration conversion services. For the complete list of such pre-defined calibration type names, see CalibData/src/CalibModel.cxx.

In order for the calibration type to be accessible to the Gaudi framework its corresponding class must have a known CLID. These also may be found in CalibData/src/CalibModel.cxx.

Write the class

The class must inherit from CalibData::CalibBase which in turn inherits from the Gaudi class DataObject and satisfies the Gaudi interface IValidity. CalibBase keeps track of the validity interval for the object so that it will be updated "automatically" as needed to keep pace with incoming events. Additionally it provides a service, getSerNo(), which may be used to determine if the object has been updated, and contains the virtual function update(CalibBase& other), which lays some responsibilities on authors of derived classes.

When an update is called for, the sequence of events is something like the following:

1. An object of the appropriate type already exists in the TCDS.
2. An update method in CalibMySQLCnvSvc gets called which invokes the appropriate conversion service (XML or ROOT) which in turn finds the right converter to make a new object of the correct type.
3. CalibMySQLCnvSvc knows nothing about types derived from CalibBase. For the new object which has just been created and also for the original object it has pointers of type (DataObject *). Since both of these are known to actually be at least (CalibBase *) it does a dynamic cast on each of them. The resulting pointers are called pBase and pNewBase. CalibMySQLCnvSvc then calls pBase->update(*pNewBase).

Any class, say one called CalibDer, derived from CalibBase must implement an update(CalibBase& other) method, whose job is to copy fields in other which are specific to CalibDer. Of course other must "really" be a reference to a CalibDer object, but the way update gets called guarantees that it will be. Typically update for such a derived class will first make a dynamic_cast of other to a reference to an object of its own type, call CalibBase::update on this reference, then copy any other data from this reference to itself. The implementation for a very simple derived class called CalibDer with a single data member m_value would look like this:

void CalibDer::update(CalibBase& other) {

  // Following dynamic cast is guaranteed to work
  CalibDer& otherDer = dynamic_cast(other);

  // Let CalibBase handle its own data
  CalibBase::update(otherDer);

  // Copy our data
  m_value = otherDer.m_value;
}

Finally, don't forget that any DataObject (hence any class derived from CalibBase) must implement the methods

   const CLID& clID() const;
   static const CLID& classID();

Design persistent form and write the converter

The calibration data class may be and probably should be in a package maintained by the subsystem. The associated converter can only be in the package CalibSvc. There are separate source subdirectories for ROOT and XML converters. The converter XmlBaseCnv does the work needed for any persistent XML representation: It parses the XML file, stores validity interval and serial number information (which comes from the metadata, not from the XML file), and causes the correct converter to be called for the remainder of the conversion. I don't know if an analogous base class is appropriate for ROOT.

Converters need to be declared to Gaudi. See CalibData/src/Dll/CalibData_load.cxx.

Gaudi and Calibration Infrastructure

GLAST Software Home

J. Bogart

Last modified: