QC: Trending of calibration parameters from CCDB

O²
1

Hi @bvonhall and @pkonopka

reading the QC documentation on trending I see

In the future we will also support access to the CCDB.

Is that already possible? We would like to monitor the results from calibration tasks running on the aggregator EPNs in a trending task. E.g. the TRD produces gain values for each chamber in an interval of 15 minutes and writes them to the CCDB. I would like to have a trending plot showing the evolution of the gain values over a long time period, for example a month.

Is there maybe even an example already how to do this?

Cheers,
Ole

2

Hi @oschmidt ,

Piotr will be back next Tuesday and he will be able to answer your question better than myself.

Cheers,
Barth

3

Hi Ole,
Trending Task still does not have this feature. We can raise the priority if you’d like, but it would still mean ETA of a few months. The “framework” of Reductors assumes though that anything that we trend is a TObject, but perhaps we can extend it to take a void pointer as well.

This being said, I know that some detectors do trend values in CCDB already, having written their own post-processing tasks. Some examples:

Can you indicate if you would like to generate this plot regardless of the data-taking activity at P2? I.e. should this start and end together with runs, or run always in the background? If the latter, I would also suggest to run it as a long-running service with nomad. We have already working machinery to do so.

4

Hi Piotr,

thanks for your reply. From the two examples which you posted it is not fully clear to me how such a trending should be done / configured. It is not super urgent right now, but would be good to have for next years data taking.

In general there are some trends which should run in the background (e.g. based on DCS DPs which are not coupled to a run) and some which are only monitored when we take data, e.g. the ones based on online calibration tasks.

Cheers,
Ole

5

Sure, I can provide more detail. First of all, this assumes that you write your own post-processing task. In case that you’d like to execute it uncoupled to data acquisition runs, you would configure triggers of the postprocessing task as such:

        "initTrigger": [
          "once"
        ],
        "updateTrigger": [
          "30min"
        ],
        "stopTrigger": [
          "userorcontrol"
        ]

The first one just asks to initialize the task as soon as it can.

The 2nd tells the framework to call your overriden PostProcessingInterface::update method each 30 minutes. Then you can retrieve your object based on the timestamp of the trigger, as in here:

void MeanVertexPostProcessing::update(Trigger t, framework::ServiceRegistryRef)
{
  std::map<std::string, std::string> md, headers;
  auto* meanVtx = mCcdbApi.retrieveFromTFileAny<o2::dataformats::MeanVertexObject>("GLO/Calib/MeanVertex", md, t.timestamp);

Alternatively, you could also use the following update trigger:

        "updateTrigger": [
          "newobject:ccdb:GLO/Calib/MeanVertex"
        ],

this will ask the framework to invoke PostProcessingInterface::update only when it sees a new object written in the CCDB at GLO/Calib/MeanVertex.

Based on your retrieved object you can generate plots and register them for publication.

The stopTrigger is configured to invoke finalize only when someone manually stops the application.

Let me know if something else is unclear.