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.
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.
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.
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.
You can find here
the sample root files.
Send
comments to Max Goncharov (mailto:maxi@fnal.gov)
Last revised: 10/11/2002