from the TPC we have a running PID workflow already since some time in QC and I am currently setting up a corresponding workflow also for the TPC QC Tracks task. From @wiechula I learned, that for the passing of the TPC tracks from the workflow in QC to the O2 task,
gsl/span should be used instead of a vector. I managed to implement this in a way it (finally, after some struggles) compiles, but when I run the task, I get errors like the following:
[27195:QC-TASK-RUNNER-Tracks]: [17:59:16][ERROR] Exception caught: Inconsistent serialization method for extracting span
I get these errors both when running in “sampled” and in “direct” mode. In the end, the histograms are published, but empty. Looking at the printouts, I do not even get the
monitorData messages, so it seems the issue is already in getting the TPC tracks in the monitorData function within the QC workflow.
My code in QualityControl is available in this draft pull request.
The corresponding part in O2 is in this branch, although, as stated, I think the issue is here in the QC.
I have searched a bit and found a similar issue in a PHOS O2 pull request, but I don’t see, what I have to change, as we already use
#include "DataFormatsTPC/TrackTPC.h". Maybe, something has to be changed over there? Maybe @shahoian could you have a look?
Thanks for any help!
I see that you are using the RootTreeReader to read the tracks, it enforces root serialization for data it publishes, even though the tracks are POD objects and can be directly messaged (which is necessary to access them as a span). This is known problem and @richterm is working on this.
On my side, in the TPC/ITS matching I am using
TPCWorkflow/TrackReaderSpec to feed the tracks into the workflow, and retrieving them as a span works w/o any problems:
see this for the workflow creation and
this for the access to TPC tracks from the matching device.
I’m working on an extension to the RootTreeReader. For the moment it is fully agnostic of the actual type and will always serialize the object from the tree. In order to use the automatic detection of the optimal serialization method, the type needs to be specified so that the API can decide whether an object can be sent without streaming.
For the moment I suggest to first try to extract the span and catch the exception, if the span fails extract the root object by specifying pointer to type, i.e.
The RootTreeWriter does the same thing
I will need a couple of days to finish the extension.
Hi Ruben, hi Matthias,
thanks a lot for your replies and explanations! If I understand it correctly, after the extensions to the RootTreeReader the code should work as I have implemented it right now, or? Then maybe the fastest solution would be, to use for the moment just a vector of TPC tracks (like in the PID task, see
QualityControl/Modules/TPC/src/PID.cxx) and only change this to the span, when the extension is available. Maybe also @wiechula can comment here.
Yes, the easiest would be to use for the moment a vector, and switch to spans once the RootTreeReader will be fixed. This is what we agreed also with PHOS.
Dear Ruben, dear all,
as Ruben has mentioned in the O2 draft PR, the usage of gsl/span should now be possible. I updated O2 and QC and tried, but I still get the same behaviour as before, i.e. the code compiles, but while running a task I get these errors:
[19140:QC-TASK-RUNNER-Tracks]: [15:38:34][ERROR] Exception caught: Inconsistent serialization method for extracting span
As before, the histograms are published, but empty, and the
monitorData line of the QCInfoLogger never appears, so the issue seems to be in the QC.
I tried to open on github a draft pull request for the changes in QC to be able to show you the code, but unfortantely that does not work either. When I click on “Draft pull request”, I get an error message (500).
Does anybody know of some issues with github at the moment?
There are problems at github at the moment : https://www.githubstatus.com/
When they are solved you should be able to create a PR that we can then look at.
You have to also modify the way the publisher is configured, see PublisherSpec.h modifications in https://github.com/AliceO2Group/AliceO2/pull/2991/files
Dear Barth, dear Ruben,
thanks for the info! I will have a look at the configuration of the publisher and also keep an eye on the github status.
I think this should now be solved with the merged PR #2991
I agree with Ruben. Lets do like this for the moment.