Hi all,
for the MID detector simulation, we need to access:
the HV of the detection elements
a set of parameters that is used for the cluster size (this is tuned once and probably won’t change)
In the Run2, the HV came from the DCS and was stored in the OCDB.
The parameters instead were hard-coded in the code (very bad practice): it would be better to move them in a database for Run3.
It is worth noting that these values are only used in simulation, not in the reconstruction phase.
What is the proper way to manage the simulation parameters? Should we use the CCDB interface or some FairRoot tool?
Thanks in advance for further information!
Dear @swenzel and @bvonhall,
do you have any suggestion on the proper way to manage the parameters that are needed in simulations? (see starting topic).
Sorry for the late reply, I missed the original post.
I would store 1. in the CCDB for sure and possibly 2. as well. Alternatively, 2. could be stored in the Configuration system.
For the CCDB, I have just migrated a class to access the CCDB from QC to O2 (see here).
For the Configuration, there is the Configuration library (see here).
In both cases, I am not sure whether the long term plan is to access directly or to have the devices populated by an external power (e.g. Control, DPL, FairRoot…). For now, I guess the best is to use directly the interfaces.
There, one could declare a variable as being such as parameter knob, which would trigger automatic configuration file creation and tuneability from the command line.
Please take a look if this would help you.
We need yet to instigate a discussion how such a system (which I believe we need) plays together with CCDB.
dpl has a way ti declare “configparamspecs” in the workflow. The idea is that depending on where you run you get them populated by Configuration (in production) or e.g. command line. That said I would try to keep any physics affecting parameter as part of either the data stream or ccdb, where we should expose knobs to modify them.
Hi all,
thanks a lot for the input.
Actually, for what concerns point 2, I have 2+2+234 values representing the parameters of the fired probability distribution function that are typically obtained from an analysis on data an then should in principle not change unless we replace the detection element in the cavern.
So I don’t actually need to change those parameters command line (also it would not be very practical, given the large number of parameters involved).
I would therefore say that these parameters would better fit the CCDB. Still, I will take the pod-variables and the configparamspecs options into account if I need them in the future.
Yes, the case you describe looks like a prime example of something which should go into CCDB, IMHO. My plan for DPL is to make sure interaction with CCDB and proper prioritisation of multiple object namespaces (where users can add their customisation) is gracefully handled (and the namespace ordering could be what you override from the command line). I’ve something ongoing which should result in CCDB integration soon, but not yet finished (and this week I am away at a Conference). We should keep @grigoras in the loop as well.
Hi @eulisse,
some time ago we were discussing on using the CCDB in simulation (or even reconstruction).
You mentioned about an ongoing development to integrate the CCDB in the DPL: do you have any news on this point?
The CCDB objects can change at run time, so they cannot be initialised in the DPL init function.
Passing them as inputSpec won’t work either…unless of course there is a way to pass an asynchronous inputSpec. Maybe there is some kind of “notify” function in the DPL for CCDB?
Sorry for the naive question, but I could not find an answer in the doc or an example in the code…
Ciao, sorry for the delayed answer. I’ve done an update for CCDB support in
At the moment it always fetch the input from CCDB, but for the future I foresee both adding support for the Caching features of CCDB and for some sort of asynchronous path where the fetching actually happens via a separate device.