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?
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.
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.
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:
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: