4 Example Walkthrough
4.1 Example to Save Conditions to a ROOT File
To illustrate the usage of the DDCond package when saving conditions, an example is discussed
here in detail. The full example is part of the conditions unit tests and can be found in the
examples.
(See examples/Conditions/src/ConditionExample_manual_save.cpp).
The examples uses conditions names and detector element names explicitly and hence requires a fixed detector description being loaded in memory. For simplicity we use here the Minitel example from the examples/ClientTests. However, the example is very generic and also the conditions are ”generic”, hence any geometry would work.
Prerequisites:
A valid compact geometry description to be loaded during the program startup.
Plugin Invocation:
A valid example conditions data file is required. Then use the default way to invoke plugins:
Example Code:
int num_run = <number of condition loads>; const string conditions = <conditions file name>; const string geometry = <geometry compact xml description"; description.fromXML(geometry); description.apply("DD4hep_ConditionsManagerInstaller",0,(char**)0); ConditionsManager manager = ConditionsManager::from(description); manager["PoolType"] = "DD4hep_ConditionsLinearPool"; manager["UserPoolType"] = "DD4hep_ConditionsMapUserPool"; manager["UpdatePoolType"] = "DD4hep_ConditionsLinearUpdatePool"; manager.initialize(); shared_ptr<ConditionsContent> content(new ConditionsContent()); shared_ptr<ConditionsSlice> slice(new ConditionsSlice(manager,content)); const IOVType* iov_typ = manager.registerIOVType(0,"run").second; if ( 0 == iov_typ ) except("ConditionsPrepare","++ Conditions IOV type registration failed!"); Scanner(ConditionsKeys(*content,INFO),description.world()); Scanner(ConditionsDependencyCreator(*content,DEBUG),description.world()); // Have 10 run-slices [11,20] .... [91,100] for(int i=0; i<num_run; ++i) { IOV iov(iov_typ, IOV::Key(1+i*10,(i+1)*10)); ConditionsPool* iov_pool = manager.registerIOV(*iov.iovType, iov.key()); // Create conditions with all deltas. Use a generic creator Scanner(ConditionsCreator(*slice, *iov_pool, INFO),description.world(),0,true); }
Explanation:
Line |
|
1-3 | Definition of processing parameters. |
5 | Load the detector description using the compact notation. |
6 | Install the conditions manager implementation using the plugin mechanism. |
8 | Access conditions manager instance from the Detector interface. |
9-11 | Configure the properties of the conditions manager. |
12 | Initialize the conditions manager instance. |
14-15 | Create an empty instance the container with the desired conditions content. |
17 | Register IOV type the Conditions Manager. The IOV types are part of the conditions persistency mechanism. They may not change with time and have to be defined by the experiment once and for all! |
18-19 | This is example specific and only a shortcut to fill the required conditions content and the
derivation rules. |
18 | Populate the instance with the addresses (keys) of the conditions required: We scan the hierarchy and add a couple of conditions for each |
19 | Add for each
3 derived conditions, which all depend on the persistent condition derived_data. |
4.2 Example to Load and Prepare Conditions(Slices)
To illustrate the usage of the DDCond package when loading conditions, an example is discussed
here in detail. The full example is part of the conditions unit tests and can be found in the
examples.
(See examples/Conditions/src/ConditionExample_manual_load.cpp).
The examples uses conditions names and detector element names explicitly and hence requires a fixed detector description being loaded in memory. For simplicity we use here the Minitel example from the examples/ClientTests. However, the example is very generic and also the conditions are ”generic”, hence any geometry would work.
Prerequisites:
A valid example conditions data file is required, since in this example we load the conditions and inject them
to the store from an already existing root file. To obtain such a file for a given geometry, execute the example
plugin:
Plugin Invocation:
A valid example conditions data file is required. Then use the default way to invoke plugins:
Example Code:
int num_run = <number of condition loads>; const string conditions = <conditions file name>; const string geometry = <geometry compact xml description"; description.fromXML(geometry); description.apply("DD4hep_ConditionsManagerInstaller",0,(char**)0); ConditionsManager manager = ConditionsManager::from(description); manager["PoolType"] = "DD4hep_ConditionsLinearPool"; manager["UserPoolType"] = "DD4hep_ConditionsMapUserPool"; manager["UpdatePoolType"] = "DD4hep_ConditionsLinearUpdatePool"; manager["LoaderType"] = "root"; manager.initialize(); shared_ptr<ConditionsContent> content(new ConditionsContent()); shared_ptr<ConditionsSlice> slice(new ConditionsSlice(manager,content)); Scanner(ConditionsKeys(*content,INFO),description.world()); Scanner(ConditionsDependencyCreator(*content,DEBUG),description.world()); const IOVType* iov_typ = manager.iovType("run"); for ( int irun=0; irun < num_runs; ++irun ) { IOV iov(iov_typ,irun*10+5); ConditionsManager::Result r = manager.prepare(iov,*slice); if ( r.missing != 0 ) { except("Example", "Conditions prepare step for IOV %s FAILED. There are %ld missing conditions.", r.missing, iov.str().c_str()); } Scanner(ConditionsPrinter(slice.get(),"Example"),description.world()); }
Explanation:
Line |
|
1-3 | Definition of processing parameters. |
5 | Load the detector description using the compact notation. |
6 | Install the conditions manager implementation using the plugin mechanism. |
8 | Access conditions manager instance from the Detector interface. |
9-12 | Configure the properties of the conditions manager. |
13 | Initialize the conditions manager instance. |
15-16 | Create an empty instance the container with the desired conditions content. |
18-19 | This is example specific and only a shortcut to fill the required conditions content and the
derivation rules. |
18 | Populate the instance with the addresses (keys) of the conditions required: We scan the hierarchy and add a couple of conditions for each |
19 | Add for each
3 derived conditions, which all depend on the persistent condition derived_data. |
22-31 | Emulate a pseudo event loop: Our conditions are of type ”run”. |
23 | This is the IOV we want to use for this ”processing step”. The conditions filled into the slice during the prepare step will satisfy this IOV requirement. |
24 | Conditions prepare step. Select the proper set of conditions from the store (or load them if needed). Attach the selected conditions to the user pool. |
25-29 | Check the result of the prepare step. If anything would be missing, the parameter r.missing ofthe return code would be non-zero. |
30 | Emulate data processing algorithms: Here we only scan the
tree and print all conditions. |