Parameter handling in HYDRA and HGEANT

Overview

To run an analysis or a simulation, initialization parameters are needed.

For the simulation one needs the full HADES geometry taking into account different target configurations and the different alignment of detectors for a specific beam time.

Each task in the analysis needs special sets of parameters, which are stored in container classes in memory.
Some tasks might share the same container (e.g. geometry parameters are needed for digitization, tracking, the event display, etc.).

The parameters are valid for very different time scales.
Once a detector is built, some parameters are fixed for the whole lifetime of this detector (e.g. number of wires in a given layer of a MDC). Containers holding such data must be initialized only once in an analysis.
Some parameters might change seldom, others quite often (e.g. calibration parameters). In these cases, a reinitialization might be needed during the analysis of several event files (To save memory and time, each container is created only once).
A task might also change parameters during the analysis of an event file and it is then necessary to save these data before a reinitialization.

In the analysis all initialization data are managed by the so-called runtime database.

All parameters are permanently stored in the HADES Oracle database.
It stores all actually valid and historic parameters for all beam times.
Web-based interfaces (WebDB) provide additional access to the data in Oracle without running an analysis.

The design of the database tables is not the same for all parameter containers. It has developed over the years and with increasing experience.

Some of the tables are closely related to the technical structure of the detectors, as they hold not only parameters needed by the analysis, but also information about the electronic setup and the cabling. As a result the data are spread over a large number of tables.
Other containers with large amounts of data in a tree like structure are stored in a certain fixed schema (tree style parameter containers). All of these containers needs special interface functions to retrieve the data.
But most parameter containers developed in the last years use a fixed layout and data are read and stored with a base class interface (condition style parameter containers).

Almost all parameter containers need a version management to keep track of changes.
One version is valid for one or more event files characterized by the run id. For the same run, even several versions of parameters might exist, for example a first version of calibration parameters, a second version after a more detailed analysis, etc. It must be possible to read also these historic data in the analysis.

Some parameters even come with different flavors, called context, for example wide cuts or strong cuts.

For daily work one needs an additional storage medium for the runtime database: ROOT files have been foreseen to store parameter sets as objects.
For several reasons a local version management has been implemented:

• To be sure to have all initialization parameters available to run batch jobs.
• To hold the parameters locally outside GSI and to avoid net traffic.
• To distribute the parameters within the collaboration when the direct access to Oracle is not possible or too slow or when the newest data are not yet written to the database.

To have an easy way to edit or create parameters, an interface to ASCII files has been implemented as well.
The aim was not to store all data temporarily in ASCII files, but to have an easy way to change parameters with an editor or to compare different versions.

The initalization concept has evolved over several years (and is still ongoing). Some features, strongly requested at the beginning, were in fact never used. Other features were missing and added later. This all makes the runtime database very flexible, but sometimes tricky to use.

Links

The runtime database

• Container factories
• Parameter containers
• Parameter I/O
• The Oracle interface
• Simulation projects
• Example initialization macros
• The parameter file generator
• How to store parameters in Oracle

The geometry interface

• Examples for HGEANT configuration files and ROOT macros

Oracle WebDB

-- IlseKoenig - 16 Jun 2007