As part of the trending of the TPC, we are also interested in variables which require information from other detectors or external sources, like for example the matching efficiency between ITS and TPC.
Is this connection between different inputs already implemented in the current framework? If not, is something like this foreseen?
I assume you have the QC post-processing in mind.
The answer is - it depends where do you want to get this data from. If e.g. matching efficiency will also be stored in the QC repository (as the results of your post-processing), then it will be naturally available, as any other QC object. It shouldn’t be also a problem if you want to access it from the main CCDB, then you might access that data in your post-processing task, or we extend TrendingTask to also get data from there.
Thanks a lot for your answer!
We are aware, that in general we can use things that are published on qcg and it would be also good to be able to get data from the CCDB.
To formulate our questions a bit more precisely, we have the following points:
At some point, we want to correlate external parameters like temperature or interaction rate to our TPC-qc observables. To do so, we of course have to access these quantities. Is it foreseen, that there will be a standalone task, which will deal with uploading such external parameters to a commonly accessible database like qcg or CCDB so that everyone can use them?
Another point we have is the creation of correlation plots, for example correlations between our TPC-qc observables and observables related to other detectors e.g. from ITS or to external parameters as mentioned before. Does such a Task/Class already exist? And if not, is it foreseen that it will be created, such that it fills the correlation plot for two observables?
The temperatures and other DCS datapoints will be available on the DCS FLP, While the interface to the DPL is still being clarified, every detector will need to process online the snapshots of DCS data points and put on the CCDB the objects with DCS info relevant for the detector.
Similarly, the interaction rate: it will be accessible from the CTP CCDB objects, but most probably will be also sent with STF from CTP FLP.
thanks a lot for this info! So if I understand correctly, what concerns the DCS data points we should discuss within the TPC, what is needed, not only for QC but e.g. also for calibration. What is not clear to me is, where the online processing to create the TPC snapshots of DCS data should run.
Concerning the interaction rate, I think we should be able to access it then from the CTP CCDB. I am not sure, whether we see the STFs in the QC, in most parts of the QC for sure not, as these will run on EPNs or QC servers. But if we can access the info from the CCDB, then it should be fine.
For the DCS: so far we were discussing 2 approaches: to ship the DCS data from the FLP to EPN as a raw data or to process it immediately on the FLP and to populate the CCDB directly from there. I think we are converging to FLP processing, but it any case, consumers of DCS data can assume that it will be available from CCDB. And yes, the detector should decide which data points it needs.
You should be able to use TrendingTask for that. However, instead of plotting one observable against time, you can plot it against other observable. Unless I am missing something here?
You can also write your own Post-processing Task which would do the job, if you need highly customised behaviour.
QC will also run on FLPs and you can have a QC Task on an FLP if you need.
Hi, @shahoian, very good, we will discuss within the TPC which DCS data we need.
@pkonopka, thanks for the info. Concerning the correlation plots, we will try (with Cindy and Marcel) to use the TrendingTask to plot one observable as a function of an observable other than time.
What concerns the external data, we for sure will have at least one QC task running on an FLP, but the external info we need probably mostly (or only) in QC tasks running on EPNs or QC servers. In principle, we could also use the FLP task to store anything we need, but in the end, if the information anyhow is available on the CCDB, we do not want to double the same data and use it from the CCDB.