Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Intern. region
Vertex Tracker
Drift chamber
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

The EmcDigiCalib Package

This file is /BFROOT/www/Detector/Calorimeter/software/digicalib.html.
Emc software page

Update History

Feb 26, 1999  Update for new BaBar web and move under BFROOT
Nov 18, 1998  Original version, borrowing from the package README file.


This Web page describes the EmcDigiCalib package. The aim is to provide sufficient detail to allow a user to add a new calibrator method to the system. Class descriptions are essentially taken from the package README file, in some cases extra details have been included here. Please note that this is a new page which is still under development. Please be patient.

[Reference material]
[What does the package do?]
[How does the package do it?]
[Adding a calibration method]
[Building an executable]
[Class descriptions]

Reference Material

You can find additional detailed information in these references.

What does the package do?

The EmcDigiCalib package is responsible for:
  • Writing the calibration algorithm names to the database at loading time.
  • Reading out a list of valid single crystal energy calibration algorithm names, reading out calibration constants, then building calibrator objects from this information and suppling a list of them on demand.
A note on terminology:

A calibration algorithm is what the calibration curve looks like as a function of, for example, energy.

A calibration method is the way in which the calibration constants were derived (not done in EmcDigiCalib).

The important point is that algorithms and methods are independent. A given algorithm can have more than one implementation in terms of different methods. A given method can use more than one different type of algorithm.

How does the package do it?

The package can be thought of in two main parts, the `machinery' which interacts with the database, and the calibration algorithms which can be added in a relatively simple way. Examples of such calibration algorithms are EmcPointDigiAlgorithm and EmcLinearDigiAlgorithm.

A good way to get an idea of the mechanism for reading/writing to the database within the package is to try running the test job as explained below.

First a dummy event is created using EmcDummyInputModule (which can be found in the EmcEnv package). In normal running this step would of course be unecessary. Next comes the building of the general and EMC environments.

The EmcLoadDigiCalib module starts the process of putting the algorithm list proxy into the environment. The algorithm list contains an entry for each of the calibration methods contained within the EmcDigiCalib package. (As well as the algorithm name and method, a flag to specify whether or not that method is default is also contained in the list. The default calibration method may of course change with time, the default flags will vary for different events accordingly).

A proxy is required to transfer the information from the transient list of single crystal calibration algorithms, to a persistent list, which is stored in the database.

The list can then be read out from the database. A proxy is required again to retrieve the persistent list of calibration algorithms from the database, and turn it into a transient list which is cached for later use.

Adding a calibration algorithm

Extra calibration methods can be added to the package relatively simply. For example, you might decided that you would like to use an algorithm which is a particular function of energy, fitting points from three sets of calibration constants (from existing methods).

(Please note that, if you wanted to add an entirely new calibration type, EmcDigiMethodList would also need to be modified).

To produce a new method, you would need to:

  • Write new classes for the method. (You would not need to add new classes if you just wanted to create a new linear method, modifying the existing linear classes would be suffice). You may name the files something like and An existing method such as EmcPointDigiCalibrator could of course be used as a starting point.
  • Add the alogorithm as a module in

    #include "EmcDigiCalib/EmcMyDigiAlgorithm.hh"

    AppModule *myAlgorithm = new EmcMyDigiAlgorithm("EmcMyAlgorithm","Bhabha+Src+MinI", 1);

    The constructor arguments here are (from left to right):

    • Module name, can be anything
    • Constants to use. Has to be an allowed string corresponding to a set of calibration constants (see EmcDigiMethodList for available strings). For example, Bhabha or Src. For methods that can use more than one set of calibration constants, the argument would be written in the form Bhabha+Src.
    • Flag for default, can be 0 or 1.
  • Add the relevant lines to

    #include "EmcDigiCalib/EmcMyDigiCalibrator.hh"

    _calibs->append(new EmcMyDigiCalibrator());

To add your calibration method to the test job:

  • Add your method to

    #include "EmcDigiCalib/EmcMyDigiAlgorithm.hh"

    add(new EmcMyDigiAlgorithm("myDescription", "Bhabha+Src+MinI", 1));

    If you set your new method as default, then when you run the test job, you will see a message similar to this at run time:

    Warning. You have asked for algorithm myAlgorithm with method Bhabha+Src+MinI to be the default algorithm. This is a change to current default: Point with method Bhabha Are you absolutely sure about this. (y/n)

    This output is avoided if you set the default flag to zero for all ather methods.

Building an executable

A good way to get an idea of the mechanism for reading/writing to the database within the package is to try running the test job. By building an executable and running the test.tcl script, you will be:
  • Creating a dummy event
  • Making a list of calibrators
  • Loading the list into the database
  • Reading the list back out
  • Retrieving a list calibration constants and producing an EmcDigiCalibDict which is stored in the environment.
To build a test executable, try the following steps:

As of 11/23/98 extra packages are still required to satisfy dependances. (The package is still under development). As a result, the following instructions will be insufficient to allow the building of a test executable. If you have a problem please do not hesitate to get in touch with James Weatherall or Jonathan Fullwood .

  • Check out a new release

    newrel -t 7.6.1 digiCalib761

    cd digiCalib761

  • Import a database as described in the Beta tutorial
  • Add the EmcDigiCalib package

    addpkg EmcDigiCalib

  • Build libraries and binaries

    gmake EmcDigiCalib.all

  • Run the executable

    cd workdir

    bin/$BFARCH/EmcDigiCalibApp ../EmcDigiCalib/test.tcl

Output from the test job will indicate whether each step has been successfully completed.

Classes included in the package

Contained in EmcEnv (to avoid circular dependancies)


Base class for storing algorithms capable of generating a crystal by crystal calibration for the EMC. The job of this class and its derivatives is to load the names of single crystal calibration algorithms into the database.


Persistent stroage of current single crystal calibration algorithm names in the Emc. Consists of an ooVArray of EmcDigiAlgDescriptions, which are nothing more than a name, a method and an indication of the default.


Simple class to describe a calibration algorithm by a name and a method and indicate whether it is the default.


Transient version of EmcDigiAlgBank, which contains information on which calibration algorithm (names and associated methods) are currently avaliable for single crystal energy corrections and which is the default.


Designed to retrieve the EmcDigiAlgBank (persistent list of which single crystal calibration algorithms are avaliable), turn it into a transient EmcDigiAlgList, and cache that for later use. Borrows heavily from EmcAlgListProxy which borrows heavily from SvtDetectorProxy.


Singleton class whose job is to keep track of known calibration algorithms for EmcDigis and register them in the database.


Designed to retrieve banks of single crystal calibration constants from the DB and turn them into a transient EmcDigiCalibDict, and cache that for later use. Takes as a constructor argument the type of constants it is to retrieve.


Responsible for ownership of all currently known EmcAbsDigiCalibrat or deriviatives. Does not know anything about their contents.


Sets up standard modules for loading EMC digi calibration information into the EMC conditions database.


Module to test retrieval of the list of digi calibrators from the database.


Factory method to provide access to the EmcAbsDigiCalibrators contained by the EmcDigiCalibList.



Just a place to centrally collect all known types of EMC single crystal calibration constants(or methods of obtaining a calibrati on). A helper, really, to assist the calibrators when it comes to deciding whether the constants they are to contain are kosher.


EmcAbsDigiAlgorithm derivative responsible for storing details of straight line energy correction algorithms.


EmcDigi calibration class implementing a straight line energy correction. This means that the correction depends on energy. The input data for this class may be from two or more different calibration methods(e.g. Bhabha _and_ source). In the case of two inputs, a straight line is drawn through them. The case of more than two calibration methods is handled by doing a piecewise linear interpolation/extrapolation between/beyond the individual points.


Puts the initial algorithm list proxy into the environment.


EmcAbsDigiAlgorithm derivative responsible for storing details of single constant energy correction algorithms.


EmcDigi calibration class implementing a single factor energy correction. This means that we apply a single constant to each EmcDigi in order to calibrate its energy. The constants could be derived from Bhabhas, radioactive source or whatever(each set of instances of the class know which type of constant they are supposed to be dealing with).

Contained in the EmcEnv package


Base class for single crystal calibrations in the EMC. Subclasses should implement the energyOf() function.


Please email questions, comments and suggestions to Jonathan Fullwood.
Your feedback is appreciated.

[Back to the top] [Emc software page] [BaBar Home] Last modified 26 February 1999