Creation of parameter files for the analysis

To run a full analysis one needs a long list of parameter containers. Some of them have different versions for the runs in a beam time.

To initialize directly from Oracle in analysis jobs on the batch farm is not recommended, because it puts quite some load on the Oracle server, if many jobs start in parallel. To avoid overload only a certain number of jobs may read data in parallel (implemented in our software). The others have to wait until the number of actively reading jobs is below a certain limit. This not only slows down the DST jobs, but hurts also all other people on desktop machines, which want to read parameters from Oracle.
Use a ROOT parameter file, if you want to run many jobs on a batch farm!

People outside GSI may not have an Oracle client installation and they need a parameter ROOT file to run the analysis.

There are two ways, to generate such a file:

Parameter file for a single run:

Define in the analysis macro the output in the runtime database. %begin c++% HParRootFileIo* output=new HParRootFileIo; output->open("allParams.root","RECREATE"); rtdb->setOutput(output); %end% Run the analysis for one file with a few events.
Then use this file for the analysis of all files. You must specify the run id, which is in the file, as reference run id.

This works fine for the analysis of simulation runs, where anyhow all files have to be initialized with the run id of the simulation reference run (see Simulation projects) as reference run.
Also for a high-level analysis this might work, because the parameter containers needed typically have only one version for a complete beam time.

But to use reference runs for the analysis of HLD files, the usage of reference runs is difficult, because you need a new reference run any time one of the versions of the parameter containers change.

Parameter file generated with HParamFileGenerator

It allows to generate a parameter file from Oracle containing all run ids in some part of a beam time (or even a whole beam time) with only a few lines of code in the analysis macro:

Old-fashioned analysis macro:

1. Add the following lines after the definition of the inputs (rtdb is the pointer to the run time database): %begin c++% // generate a parameter file for beam time aug04 if (rtdb->makeParamFile("paramsAug04.root","aug04")) { delete gHades; return; } %end% Do not specify an output in the macro. It is created automatically by the runtime database.

For long beam times with a large number of runs, it is strongly recommended to generate several parameter files, eventually even one per day. (It takes quite some time to generate the file and you might have to run it again, because some stuff is missing).
You do this by specifying a time range: %begin c++% // generate a parameter file for one day of beam time aug04 if (rtdb->makeParamFile("paramsAug04242.root","aug04", "29-AUG-2004 00:00:00","29-AUG-2004 23:59:59")) { delete gHades; return; } %end% 2. Add the following line at the end of the macro directly before the delete of Hades: %begin c++% rtdb->saveOutput(); %end% 3. Then run the macro with 1 or 2 events.

Description

The function HRuntimeDb::makeParamFile takes at least two arguments: the name of the ROOT output parameter file and the experiment name (not case-sensitive).
You may shrink the time range by specifying also a range begin and/or a range end ( accepts dates, hld-filenames or run ids).

The ROOT file is opened with option "CREATE" and will fail, if the file exists already. Therefore one should check the return code of the function.

After the first event, the runtime database has the complete list of parameter containers actually needed. The initialization of all runs in the specified range is activated in HRuntimeDb::saveOutput(). It gets from Oracle the complete list of files on disk in the specified range (uses function getListOfRuns in HOraInfo) and initializes all containers for each run.
The loop does not break, if a parameter container cannot be initialized (different from HRuntimeDb::initContainers(Int_t)).

Additionally to the ROOT parameter file a log-file is created with the same name, but with extension ".log".
This file contains four parts:

1. The list of runs with filename, run id, start and stop time
2. The list of parameter containers
3. The number of runs, not fully initialized and for these runs the list of missing containers. Search for "Error" to find these messages.
4. The version management table for all runs

The function makeParamFile may also be called with the name of a simulation project, e.g. "aug04sim". In this case the parameter containers will be initialized for all reference runs in this project (only the last generation in each sub-project).

-- IlseKoenig - 28 Jun 2007