You are here: Hades Wiki>Homepages Web>HadesRtdbIlseKoenig (revision 1)EditAttach

Parameter initialization in HYDRA and HGEANT

Overview

To run an analysis or a simulation, initialization parameters are needed. 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 by the digitization, the tracking, the event display, etc.). For the simulation one needs the full HADES geometry taking into account different target configurations and the different alignment of detectors for a specific beamtime.

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.

All initialization data are managed by the so-called runtime database.

rtdb_overview.gif

All parameters should be permanently stored in the HADES Oracle database. It stores all actually valid and historic parameters for all beam times. Web-based interfaces 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 cabeling. As a result the data are spread over a large number of tables. Other containers with large amounts of data in a tree like stucture are stored in a certain fixed schema. All of these containers needs specicial 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.

Allmost 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, e.g. 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 flavours, called context, e.g 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 e.g. for running 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 temporary data 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 years. 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.

-- IlseKoenig - 16 Jun 2007
Edit | Attach | Print version | History: r6 | r4 < r3 < r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r1 - 16 Jun 2007, IlseKoenig
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)