Issue with TTree::Draw in QC environment

Dear @bvonhall, @pkonopka and other experts,

We would like to use vectors of struct in the trending of the TPC, as we want to look at different sectors/pads and/or different numbers of subranges of histograms (called a slice).
We managed to have the outcome of the reductor as a vector in the trending tree, but we encounter now an odd behaviour when it comes to the drawing of the trending.

Currently, we are saving the trending tree into this ROOT file. The provided example contains the trending of the pseudorapidity distribution sliced into different ranges (in this case positive and negative ranges). For each of these two slices, we calculate the relevant quantities (e.g. mean x, stddev x), save them in one struct per slice and push this struct into the vector. So each vector entry corresponds to one slice of the histogram which we want to trend. After retrieving the statistical quantities per slice, we want to draw one trending histogram per slice via the TTree Draw function.

Our current investigation found that the code runs until the call of the Draw function (i.e. the vector of structs is saved properly in the tree). We tried to investigate whether the draw function does not support the vector of structs, so we tried its execution in the command line of the terminal using TestTPCTH1Slicer->Draw("hEtaRatio[0].meanX:time","","L*"). With this, we want to plot the mean x of the first slice of the Eta distribution as a function of time given the treeTest.root file mentioned above.

Now, the weird issue concerns the environment where this is executed: in a normal ROOT6 environment (ROOT6-24), as well as in recent O2Physics, O2 and AliPhysics environments, this commands works as it should.
However, when used in QC environment (recently updated), this commands fails with the error in the log. However, if the code is executed immediately after the first crash, the command again works as expected.

We tried to investigate this issue with @wiechula and @sheckel, but without success. We would therefore ask if someone already encountered something similar, or had an idea of what is going on?

Thanks a lot in advance for any input/suggestion,
Cheers.
Cindy and Marcel

Dear all,

I think I have a similar, potentially related issue: I try to add within the initialize function of a QC task a display hint (i.e. logx in a 2D hist) according to these instructions. This histogram is inside a vector of 2D hists. Looping over the vector, e.g. to start publishing all histograms, works fine, but accessing a single one does not work.

If I try one of the following options (after the histograms already have been initialized), I get an error while running:
(1)

getObjectsManager()->setDisplayHint("hdEdxVsp", "logx");

(2)

auto& histDedxVsP = mQCPID.getHistograms2D().at(3);
getObjectsManager()->setDisplayHint(histDedxVsP.GetName(), "logx");

(3)

auto& histDedxVsP = mQCPID.getHistograms2D().at(3);
getObjectsManager()->setDisplayHint(&histDedxVsP, "logx");

In all cases the error is:

[771:QC-TASK-RUNNER-PID]: 2021-10-21 16:21:55.673402 !!! Error - ObjectsManager: Unable to find object "hdEdxVsp"
[771:QC-TASK-RUNNER-PID]: [16:21:55][STATE] Exiting FairMQ state machine
[771:QC-TASK-RUNNER-PID]: [16:21:55][ERROR] error while setting up workflow in o2-qc: /home/sheckel/alice/sw/SOURCES/QualityControl/tasksDev/0/Framework/src/ObjectsManager.cxx(117): Throw in function o2::quality_control::core::MonitorObject* o2::quality_control::core::ObjectsManager::getMonitorObject(std::string)
[771:QC-TASK-RUNNER-PID]: Dynamic exception type: boost::wrapexcept<AliceO2::Common::ObjectNotFoundError>
[771:QC-TASK-RUNNER-PID]: std::exception::what: Object not found error
[771:QC-TASK-RUNNER-PID]: [AliceO2::Common::errinfo_object_name_*] = hdEdxVsp
[771:QC-TASK-RUNNER-PID]: 
[771:QC-TASK-RUNNER-PID]: terminate called after throwing an instance of 'boost::wrapexcept<AliceO2::Common::ObjectNotFoundError>'
[771:QC-TASK-RUNNER-PID]:   what():  Object not found error

I.e. even when I try to access it via GetName (version (2)), it gets the correct name (hence has to have access to the correct object), but cannot retrieve the object.

Now, when I put it in the existing for loop used to start publishing, set a simple counter and try to get the correct object, this actually works:

  int count = 0;
  for (auto& hist : mQCPID.getHistograms2D()) {
    getObjectsManager()->startPublishing(&hist);
    getObjectsManager()->addMetadata(hist.GetName(), "custom", "43");
    if (count == 3) {
      getObjectsManager()->setDisplayHint(hist.GetName(), "logx");
      ILOG(Info, Support) << "--->>> Set " << hist.GetName() << " to log x" << ENDM;
    }
    count++;
  }

Unfortunately, while the if statement is entered and the setDisplayHint performed without complaining, the histogram does still not have a logarithmic x axis. But I guess, this is likely a second issue more related to this ticket.

I would be very glad about any idea!

Cheers,
Stefan

Hi, I am not sure if the root (hehe) cause is the same for these two issues.

Regarding the first one, I really can’t tell, but I remember having similar problems with ROOT working correctly with some simulation packages, but not with QC, and the issue was that alibuild was keeping separate ROOT versions for those, while it should not. The nuclear option – deleting sw and running aliBuild again - used to help for this.

Regarding the second problem, I recall that ROOT had some issues when one was trying to create more than one object under the same name. Is this the case in your vector?

Hi Piotr,

thanks for your replies! Concerning the first issue, we can try with the nuclear option, but it would be good if (at some point after the pilot beam) you could continue investigating to see, if maybe this can be solved, as otherwise we cannot rely on the stuff working in the production system, where you not just can delete the sw directory.

Regarding the second one, there is always only one object with a given names, so all names inside the vector are different. So this has to be some other issue.