Calibration Modules


Contents

* Overview

* Calibration Modules

* How It All Works

* Root Files

 

 

Overview

Currently there are 2 calibration modules, AsdThresholdMod and SlewingCorrMod, each responsible for collecting data to fill the corresponding calibration table: DetEfficiency and DetSlewing, where Det can be any of the calorimeter detectors. One has simply to clone the module and set a talk-to parameter to the desired detector system.

There are two auxiliary template classes defined for each of the table: GenericDModule and TimeCalCalibMod. GenericDModule is standard module that uses TimeCalCalibMod class to handle low-level details of committing and retrieving data from the database.

 

 Calibration Modules

All calibration modules inherit from a common parent: CalibModsBase class. They operate in a simple way: each defines the data structure it wants to keep the data in, and fills it while events are being processed. If externally triggered, the module will start performing calculations necessary to produce the final numbers.

The user can ask the module for the numbers corresponding to a particular detector tower defined by geomid.

Each module has an ability to perform auxiliary functions like saving or reading data to or from the text files, comparing current data with any tables provided externally, and deciding if the data it holds is ready for the prime time.

 

Back to top

 

Auxiliary Classes

GenericDModule is the standard module in a sense that it has talk-to parameters available. Its sole purpose is to commit or retrieve the table to or from the database. By design one module should be created to handle one calibration table. The module may not be cloned because it takes the table as a template parameter.

By design this module must know what calibration module it works together with. This can be set via a talk-to parameter or externally.

 

Back to top

 

How It All Works

One ControlModule module is designed to manage how the calibration sequence goes. The ControlModule keeps pairs of the calibration module and auxiliary module. This information is set in the talk-to. 

The magic happens at the end of the run. The control module first triggers each calibration module to perform the final calculations. Then it asks if the module thinks it is ready for the prime time. Right now the module replies "yes" if 90% of channels:

1.   collected some minimum number of events

2.   attempted the fit and the fit returned status of 2 or 3.

If one of the module replies "NO", then nothing happens, we simply collect more events.

If All modules are ready, the ControlModule asks the auxiliary module to retrieve the corresponding OLD table from the database and asks the calibration module to decide if it thinks it wants to update the information. Right now the calibration module will say "YES" if:

"Changed" here means that the OLD function applied to the current curve produces a  chi2 more than 4 sigmas higher then it should be.

If one module wants to commit a new table, then ALL modules will commit their data. In that case ALL modules are completely reset and the sequence starts from the beginning.

If none of the modules commits the data, then ALL modules are asked to decide if it is time for a reset. If ALL of them say "YES", then ALL of them are reset. The module makes a positive decision only if the number of data entries exceeds some set value in EACH channel.

 

Back to top

 

Sample Root Files

You can find here the sample root files.

 

Back to top

 

Send comments to Max Goncharov (mailto:maxi@fnal.gov)

Last revised: 10/11/2002