Option for sub-ranges in TH1 and TH2 reductors

O²
1

Dear QC-Experts,

I have a question about the existing TH1 and TH2 reductors. For the trending of the TPC, we found that, in some cases, it is important not to trend a whole histogram, but rather multiple sub-parts of this histogram and compare them to each other in the trending.

Take as an introductory example a TH2 histogram with mean of minimum ionizing particles MIPs vs azimuthal angle phi. It would not be beneficial to trend this TH2 as a whole histogram (as the reductor is currently doing) but to rather divide it into several sub-ranges in the phi direction and to trend these sub-ranges separately for comparison. This would allow to perform QC for the sectors of the TPC separately and compare them to each other.

Let us consider for now a TH1. To solve this in general, we would propose to add a section “Divisions” in the “dataSources” part of the post-processing trending json. In this part, one can define an array of size N+1 which defines the boundaries of the N sub-ranges which one wants to divide the histogram into. This could look like

"dataSources": [
          {
            "type": "repository",
            "path": "qc/TPC/MO/Tracks",
            "names": [ "hPhiAside", "hPhiCside" ],
            "Divisions": [ "Boundary_0", ...., "Boundary_N"],
            "reductorName": "o2::quality_control_modules::common::TH1Reductor",
            "moduleName": "QcCommon"
          }
        ],

Then, this array is passed to the TH1 reductor, which loops over the N divisions and performs the reduction on the sub-ranges separately. This can be achieved via the TAxis::SetRange functionality. As an output, the TH1 reductor would then not give

return "mean/D:stddev:entries";

but rather a

return "mean[N]/D:stddev[N]:entries[N]";

In the same fashion, one could pass two arrays for a TH2 histogram for N divisions along the x-axis and M divisions along the y-axis.

Is something like this already in planning? And if not, would it be possible to implement such a feature? We assume that this would be helpful also for other detectors.

Thanks in advance!

Best,
Marcel

2

Hi,
thanks for the suggestion, your use-case seems valid indeed. I am not sure yet if how this could be actually implemented with the current Reductor interface (in the initial version I didn’t expect that we would have to tell a Reductor how to reduce an object, so there is no way to pass it this kind of information). I would have to rework it a bit.
I must say that me and @bvonhall are quity busy these days with Milestone Weeks and other responsibilities, so we won’t be able to allocate some time to work on this anytime soon, I am sorry about it. Therefore, I could propose you the following ways forward:

  1. You can implement a dedicated Reductor (or Reductors) for your TPC histograms, so it would have these boundaries hardcoded within and then you can load it from TrendingTask. If different kinds of histograms share the same axes, such a Reductor could be used for many of them. This option should be quite easy and painless to implement, I suppose.
  2. You could create your own Post-processing Task (could be even an extension of TrendingTask, ITS did that), where you compute these values yourself. This is a bit more work, but you have the most flexibility.

Again, I am sorry that I can’t provide you with a global solution anytime soon, but I’ve been assigned a number of critical tasks which I have to deal first. I would recommend you to try out the 1st option, it should be easy to do.
Cheers!

3

Hi Piotr,

Thanks a lot for your answer! That’s cool that you like the idea.
No problem that you won’t have time for it immediately, we will then work on/use TPC specific versions of this for now.

Best,
Marcel

4

Great!
I’ve created a task for more global solution:
https://alice.its.cern.ch/jira/browse/QC-544