Weird behavior of vector<vector<array>> leaves in TTree::Draw

[bonventre]

The demtsh.etime leaf is a std::array of two doubles. When using TTree::Draw both etime[1] and etime[0] are identical (etime[1]-etime[0] is always 0). Tried

trkana->Draw("demtsh.etime[][][1]-demtsh.etime[][][0]") trkana->Draw("demtsh.etime[0][][1]-demtsh.etime[0][][0]") trkana->Draw("demtsh.etime[0][0][1]-demtsh.etime[0][0][0]")

and all are zero. In uproot t["demtsh"]["etime"] has the correct shape and the two values are different for each entry

[sam-grant]

@bonventre could you point me to the file you were running on so I can look at this?

[sam-grant]

I can confirm that I see the same thing.

When I scan the tree using the ROOT interface, I see that the two sets of values are identical.

root [1] trkana->Scan("kltsh.etime[][][1]")
***********************************
*    Row   * Instance * kltsh.eti *
***********************************
*        0 *        0 * 91257.687 *
*        0 *        1 * 91244.164 *
*        0 *        2 * 91259.531 *

root [2] trkana->Scan("kltsh.etime[][][0]")
***********************************
*    Row   * Instance * kltsh.eti *
***********************************
*        0 *        0 * 91257.687 *
*        0 *        1 * 91244.164 *
*        0 *        2 * 91259.531 *

When I print them out using uproot they are different, and data_["kltsh"]["etime"][[:,:,:,0] is identical to both 0 and 1 from trkana->Scan().

data_["kltsh"]["etime"][[:,:,:,1]:

91257.2265625
91243.8593750
91255.2890625
...

data_["kltsh"]["etime"][[:,:,:,0]:
91257.6875000
91244.1640625
91259.5312500
...

I have no idea why this happens! It's very strange. It seems like it might be ROOT issue/limitation?

[AndrewEdmonds11]

I've posted a question about this on the ROOT forum here: https://root-forum.cern.ch/t/problems-with-std-vector-std-array-branches/60239

[AndrewEdmonds11]

A short update on what I've found out from discussion on that ROOT thread:

• vector\<array> branches are not directly supported, but can be achieved with a workaround
• the workaround works fine for vector\<array> branches but not for the vector\<vector\<array>> branch
• replacing vector\<vector\<array>> with vector\<vector\<vector>> works even less well than the workaround
  • this may be a bug on my end so have asked the ROOT developers for more guidance

We have seen other places where TTree::Draw and TTree::Scan do not work nicely with our nested structure. We may only be able to support ROOT analyses with event-loop macros...

[kutschke]

If the ROOT team does not come up with a a timely replacement, here is a thought. Replace one of the vectors (or arrays) with your own class that contains a vector as a data product and forwards as many of the necessary fuctions of vector (or array) as needed. Possibly you could replace it with a class template of your own creation but if the issues is really depth of nested templates that won't help. With appropriate use of using this could be made transparent to the end user.

But i do recommend waiting to see if there is a proper solution.

[AndrewEdmonds11]

So the ROOT developers say that it appears what we want is too complex for TTreeFormula. So I guess for three layers of vectors/arrays, we can only loop through in compiled ROOT macros or use python...

I'll leave this issue open in case future ROOT developments make this possible. We can also use it to document other branches that have the same issue

[AndrewEdmonds11]

@kutschke: that's similar to the solution proposed by the ROOT developers that I looked into. It does seem to be the layers of nesting that's the issue so I think we're stuck...