Parameter containers

The parameters are stored in parameter containers, which are managed by the runtime database and accessible via their names.
They are all derived from a common base class HParSet.

HParSet, the base class for all parameter containers

This class defines the common data elements, some basic functionality and the virtual functions, each container class must implement for initialization and output.

Data Members of HParSet

TString fName, TString fTitle
These data members (and access functions) are inherited from the ROOT class TNamed.
The name uniquely identifies the container in the runtime database.

TString paramContext
This is the name of the parameter context
A parameter context allows to support different flavors of the parameters, which are valid for the same run.
For classes directly derived from HParSet, the context in not mandatory.
The context defined in the constructor is the default context. Others are set either via the container factory or explicitly in the macro.

Bool_t status
By default this flag is kFALSE and the parameters are initialized for each run. Once set kTRUE, the containers is skipped in the automatic initialization in the runtime database.
Set function: void setStatic(Bool_t flag=kTRUE)
Get function: Bool_t isStatic()

Bool_t changed
By default this flag is kFALSE and set kTRUE after each initialization, which signals, that the container must be written to the output before the data are overwritten by the next initialization or before the container is deleted. The write function then again resets the flag.
Set function: void setChanged(Bool_t flag=kTRUE)
Get function: Bool_t hasChanged()

Int_t versions[3]
versions[0] : actually not used
versions[1] : version of the parameters taken from the first input
versions[2] : version of the parameters taken from the second input
By default all versions are -1.

Text_t detName[10]
This is the name of the detector the container belongs to and is set in the constructor of the derived class.
It is mandory for all parameter containers which might initialize only a subset of the modules or want to check if all modules in the setup are initialized from one or two inputs.

TString author, TString description
This is the author and the comment of the parameters in Oracle and must be filled before the data are written to Oracle.

Base class I/O functions

Bool_t init(HParIo*)
If the detector name is defined, it first creates an array corresponding to the setup array of this detector.
Then it checks, if the parameter container was initialized the last time from two inputs and in this case it resets the input versions.
After this it tries to initialize the parameter container from the first input (if defined) in the runtime database by calling the init function in the derived class (described below). If this fails, because the input cannot provide the data or not all of them, it calls also the init function for the second input (if defined).
If the parameter container is then still not fully initialized it returns kFALSE, otherwise kTRUE.
Bool_t write()
This function get the output pointer from the runtime database and, if defined, with this calls the function in the derived class (described below).

Virtual functions to be implemented in the derived class:

Bool_t init(HParIo*,Int_t*)
This function initializes the container from an input using the detector specific interface class of type HDetParIo.
Eventually the integer array is used to read only a subset of the data.
Int_t write(HParIo*)
This function writes the container to an output using the detector specific interface class of type HDetParIo.
ALERT! If you want to write a parameter container to Oracle, you must use this write function with the pointer to the Oracle output as parameter. You cannot use the base class write function without an argument.
void clear()
This function resets the parameters to the default values and sets the input/output versions to -1.

Tree-style parameter containers

Since 2002 we use a standardized table layout in Oracle for a certain group of parameter containers:
  • They have a tree-like structure: sector, modules, ..., cells.
  • Typically they hold a large amount of data.
  • They are closely related to hardware modules (the data stick to the hardware module, not to the position of this module).
  • They need a version management.
  • They may have different contexts (to distinguish between different valid versions for the same run).
  • The data elements will probably not change anymore in future code releases.

Typical examples are the low-level parameter containers as unpacker lookup tables, thresholds, calibration parameters, ...

Although the parameters itself are individual (they may even be stored in several tables), they use a standard layout for the version management.
  • This allows to write parts of the analysis interface code with cut-and-paste or to reuse code (even without using dynamic SQL for performance reasons).
  • It is possible to use a generic WebDB GUI for validation and queries.
  • One can store and validate the data of the modules separately. If only the data for one module have changed, there is no need to store also all the other ones.

See here for more information about the implementation.

HParCond, the base class for condition-style parameter containers

If the list of data members of a tree-like parameter container changes, one has to change Oracle tables and views and analysis interfaces. This is quite some work and the Oracle part can be done only by someone with some SQL experience. This type is therefore not appropiate for parameter containers as for example conditions (this lead to the name) used in PID or high level analysis, where the code is not stable and changes with every major code release.

To overcome this problem a new type of parameter container has been developed. The data are stored in a generic way in Oracle and the interfaces for Oracle, ROOT and ASCII files are almost completely implemented in base classes.

  • Minimizes code development
  • No need for any new development in Oracle (no expert needed)
  • Properly implemented, it is almost code independent. People can use old and new code to read the data from Oracle.
  • Allows to store large arrays or even ROOT objects in binary format and to read these data very fast.

  • All parameter are independent. One cannot put any constraints on the data in Oracle. This has to be implemented in the code of the parameter container.

The parameter container must inherit from HParCond and implement only two functions:
   // Fills all persistent data members into the list for write.
   void putParams(HParamList*)

   // Fills all persistent data members from the list after reading.
   // The function returns false, when a data member is not in the list.
   Bool_t getParams(HParamList*)

The data are stored in Oracle either as strings (basic types int, float, double, strings, small arrays as comma separated list) or as binary large objects (BLOBS). For ROOT classes as histograms, also the streamer info is stored.
The read interface fills all valid parameters for the parameter container into lists in class HParamList used for transfer. The getParams function in the parameter container takes from the list only the parameters in the actual code version calling overloaded functions.
This HParamList contains two lists, one for parameters stored in Oracle as strings (objects of type HParamObj) and a list for parameters stored as BLOBs (objects of type HParamBinObj). For each list type it provides functions to fill the lists or to retrieve data.

  • HWallRefWinPar, a simple parameter container with two float variables
  • HWallDigiPar, a parameter container with binary float arrays
  • HMdcWireStat, as parameter container with arrays of histograms

See also How to write a "condition style" parameter container

-- IlseKoenig - 23 Jun 2007
Topic revision: r4 - 2007-07-16, IlseKoenig
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki Send feedback | Imprint | Privacy Policy (in German)