After developing the Oracle tables and interfaces for almost all parameter containers in the actual HYDRA version, this documentation should help you to make use of Oracle as a tool to get better control over parameter usage and to simplify the initialization process.
We strongly depend on your feedback. Please send us your comments and suggestions for changes or additional features.
Bugs in the code and the WebDB applications affect all users, could even spoil the data in the Oracle tables.
Please inform us immediately about unexpected behavior!The Oracle development team: Tassilo Christ, Ilse Koenig, Tomasz Wojcik
To compile and run the HYDRA Oracle interface at GSI type or add to you profile:
Most of the parameter containers have a write interface. The procedure is always the same:
The following macro shows as an example, how to store TOF calibration parameters with some Oracle specific code.
Once the data are in Oracle, you may initialize from Oracle simply by replacing your ROOT or ASCII file I/O by the Oracle I/O:
The version management in Oracle and the interface allows you to initialize for a specified run also with the parameter, which where valid in the past.
By default the history date is set to the date of the last parameter release for the corresponding beamtime or simulation project.
Parameter releases should guarantee to initialize always with a consistent set of parameters. Our parameter containers are not all independent from each other.
Once the parameters for all containers are consistent, dedicated people can make a new parameter release by filling a WebDB form.
The run id and the history date is stored automatically in the data element "description" of the parameter container and streamed to an output ROOT file.
More for completeness, rather than really needed (eventually for the analysis of simulation runs):
When reading from ROOT file, one has also the possibility to select a special version only for one parameter container with the function:
Requirements
. oraenv
Outside GSI you have to install an Oracle Client. See Logbook entry by Michael Dahlinger for instructions.
export ORA_USER=hades_ana/hades@db-hades.gsi.de
How to write to Oracle
These storage requires to login on a production account and requires a password. The default analysis user cannot store data.
The output of this macro will look like this:
{
Hades* myHades=new Hades;
HSpectrometer* spec=gHades->getSetup();
HRuntimeDb* rtdb=gHades->getRuntimeDb();
// Create the setup containing all modules you want to store
HTofDetector* tof=new HTofDetector;
Int_t tofMods[6][22]=
{ {1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
{1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0} };
for(Int_t i=0;i<6;i++) tof->setModules(i,tofMods[i]);
spec->addDetector(tof);
// Initialization here from ROOT-file
HParRootFileIo* input=new HParRootFileIo;
TString inputFile="/u/hadesdst/nov01/gen3/params/detPar/tof_params_nov01_allvers_tw.root";
if (!input->open(inputFile.Data())) {
printf("*** File %s not found ****\n",inputFile.Data());
return;
}
rtdb->setFirstInput(input);
// Use Oracle as output
HParOraIo* ora=new HParOraIo;
if (!ora->open("tof_anatest")) return;
rtdb->setOutput(ora);
// will prompt you for the password
// Create the container
HTofCalPar* pCalPar=rtdb->getContainer("TofCalPar");
// Initialize the container with the parameters you want to store in Oracle
if (!rtdb->initContainers(1007332012)) return;
// Set the author and the description, if not already in the ROOT-file
pCalPar->setAuthor("Pavel Tlusty");
pCalPar->setDescription("4th set of Nov2001 calibration parameters");
// Write the container to Oracle
pCalPar->write(ora);
// Delete Hades. This will close the Oracle connection
delete myHades;
}
To make the data available for initialization, the new version (here 21) must be set valid for a certain time range (range of runs).
...
--------------- TofCalPar ---------------
Oracle version for TofCalPar created: 21
sector_id: 1 64 rows inserted
sector_id: 2 64 rows inserted
sector_id: 3 64 rows inserted
sector_id: 4 64 rows inserted
sector_id: 5 64 rows inserted
sector_id: 6 64 rows inserted
Transaction committed
connection to Oracle closed
This can be done via a WebDB GUI by simply filling a form.
Actually two GUIs exist:
How to read from Oracle
//HParRootFileIo* input=new HParRootFileIo;
//TString inputFile="/u/hadesdst/nov01/gen3/params/detPar/tof_params_nov01_allvers_tw.root";
//if (!input->open(inputFile.Data())) {
// printf("*** File %s not found ****\n",inputFile.Data());
// return;
//}
HParOraIo* input=new HParOraIo;
if (!input->open()) return;
rtdb->setFirstInput(input);
Parameter Releases and Historic Data
Even when in the mean time e.g. better calibration parameters are valid for this run, it is possible to use the old parameters by setting the history date in the ROOT macro before the initialization of the first parameter container (e.g. after setting the runtimedb input):
input->setHistoryDate("01:MAR-2002 12:20:00");
When no release exists, the history date is set to the actual date on the Oracle server and you get the newest data.
If e.g. the calibration parameters for the START detector change and are stored in Oracle, the MDC calibration parameters made with the old START calibration parameters are not usable anymore.
Using by default the last parameter release one gets still the old parameters for both detectors. On the other hand, the person, who wants to create the new MDC calibration parameters, can read the newest START calibration parameters (and also the newest versions of all other parameter containers) by setting
input->setHistoryDate("now");
in the macro. This sets the history date to the actual date.
Releases have names and one can use the names to set the history date to the corresponding date:
input->setParamRelease("NOV01_Gen4");
The WebDB application Show parameter releases in folder HYDRA Parameters shows all parameter releases for a selected beamtime or simulation project.
Reference Runs
As for the initialization from ROOT file, also in the Oracle interface one has the possibility to specify a reference run (or filename) when adding a run to the datasource or the runtime database.
The result is the initialization for all parameter containers with the parameters for this reference run instead with the ones for the "normal" run.
The analogon in the Oracle interface is the specification of an individual reference run id (with the same function for the parameter version). Only this special parameter is initialized with the parameters for the reference run, all other with the parameters for the "normal" one.
Bool_t HRuntimedb::setInputVersion(Int_t run,Text_t* container, Int_t version,Int_t inputNumber);
You cannot specify the Oracle version, you see in the GUIs, because most parameter containers do not have a single version, but might have different ones for each sector or module. Some containers do not even have versions. Therefore the individual reference run id is the only possibility.
Restrictions
The setup of the detectors might change between beamtimes and at least for the MDC this could lead to wrong parameters.
The validation for the two run types is completely independent from each other. Even when the data are the same (and stored only once) the context id used to find the correct version is different. It is stored internally and cannot be changed on the fly mainly for performance reasons.
Actually one simulation run with run id 0 is stored in Oracle and therefore only one version for each parameter container can be stored. We have to discuss and fix the rules to store additional ones in different simulation projects with defined time ranges to attach parameters to them.