Hi ROOT-Team,
I wonder whether the mentioned issue is really completely solved or if I am being being hit by something different:
Initially, I worked with ROOT v6.20.02 and experienced the same bug as described here:
I updated to ROOT v6.20.08 (where the bug should be solved) and if I remember correctly a check involving only a very finite number of events looked promising…
But now the problem is as follows:
This will get a little bit complicated, I apologize for not providing a minimal working example:
I have two TTrees
with same different name, but in the same TFile
. I create an ad-hoc TChain
and build a RDataFrame
up on it (pretty much as described in the initial bug report). These trees contain different event classes and are labeled with _5 or _45.
My analysis somehow bins the data (here in costheta); I achieve this by corresponding RDataFrame::Filter
calls defined in a loop. These binned samples are then extracted (RDataFrame::Take
) and processed further on. The bug can be seen when comparing the size of the output vectors, which is plotted on the Y-axis, the aforementioned bins are on the X-axis:
In every bin “multi_chained” does not match single_chained (which is the same chain run single-threaded)
single_chained seems to be correct, as It reproduces a manual sum of the _45 and _5 event classes, which were obtained by the same macro, but with a single tree instead of a chain backing the dataframe). For the individual tree runs, multi-threading does not affect the results (no difference between single_45 and multi_45 or single_5 and multi_5)
I also get an error message on the terminal, which appears several times during the running DataFrame analysis. This happens only in multithreaded chain mode and thus seems to be related to the problem:
Error in TTreeReader::SetEntriesRange(): first entry out of range 0…3375163
The easiest solution for me might be to work around the problem and simply merge both trees beforehand (via TChain->CloneTree()
), but this still looks like a bug…
Regards,
Philipp