Example Walkthrough

4 Example Walkthrough

4.1 Example to Save Conditions to a ROOT File
4.2 Example to Load and Prepare Conditions(Slices)

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 $D D 4 h e p$ examples.
(See examples/Conditions/src/ConditionExample_manual_save.cpp).

The examples uses conditions names and detector element names explicitly and hence requires a ﬁxed 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 ﬁle is required. Then use the default way to invoke plugins:
$$ > g e o P l u g i n R u n - d e s t r o y$

Line
1-3	Deﬁnition 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	Conﬁgure the properties of the conditions manager.
12	Initialize the conditions manager instance.
14-15	Create an empty $C o n d i t i o n s S l i c e$ 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 deﬁned by the experiment once and for all!
18-19	This is example speciﬁc and only a shortcut to ﬁll the required conditions content and the derivation rules. In real life this would be intrinsic to the experiment’s data processing framework.
18	Populate the $C o n d i t i o n s C o n t e n t$ instance with the addresses (keys) of the conditions required: We scan the $D e t E l e m e n t$ hierarchy and add a couple of conditions for each $D e t E l e m e n t$
19	Add for each $D e t E l e m e n t$ 3 derived conditions, which all depend on the persistent condition derived_data. In the real world this would be very speciﬁc derived actions.

Line
1-3	Deﬁnition 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	Conﬁgure the properties of the conditions manager.
13	Initialize the conditions manager instance.
15-16	Create an empty $C o n d i t i o n s S l i c e$ instance the container with the desired conditions content.
18-19	This is example speciﬁc and only a shortcut to ﬁll the required conditions content and the derivation rules. In real life this would be intrinsic to the experiment’s data processing framework.
18	Populate the $C o n d i t i o n s C o n t e n t$ instance with the addresses (keys) of the conditions required: We scan the $D e t E l e m e n t$ hierarchy and add a couple of conditions for each $D e t E l e m e n t$
19	Add for each $D e t E l e m e n t$ 3 derived conditions, which all depend on the persistent condition derived_data. In the real world this would be very speciﬁc derived actions.
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 ﬁlled 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 $D e t E l e m e n t$ tree and print all conditions. We know what we expect since we deﬁned the content the same way! In the printer we can access the conditions directly from the slice, since the slice implements the $C o n d i t i o n s M a p$ interface.