Problem using PtEtaPhiMVector in compiled c++ code to extend TTree::Draw functionality

[jhowarth]

I am trying to load an external function that I can then use in TTree::Draw. If I use primitive types, this works fine, but when I try to do this with a PtEtaPhiMVector, I get the error:

Error in <TTreeFormula::Compile>: Bad numerical expression

The way I’m loading the macro seems to be fine, e.g.:

gROOT.ProcessLine(".L external_functions_C.so")

And I can use externally defined functions that use and return primitive types but I don’t seem to be able to use any of the LorentzVector classes. Does anyone have any idea how I can do this? A basic example of a function I’ve tried is:

tree->Draw("testFunc(l_vec)")

where the function is:

float testFunct(PtEtaPhiMVector L_lep_pos){
  return L_lep_pos.Pt();
}

which fails, but something like:

tree->Draw("testFunc(l_vec.Pt())")

where the function is:

float testFunct(float L_lep_pos){
  return L_lep_pos;
}

works fine. Any help would be greatly appreciated!

_ROOT Version: 6.22.06_2
_Platform: macOS Catalina 10.15.7
_Compiler: clang

---

[jhowarth]

For a bit more information, running from the command line in interactive ROOT works fine, i.e.:

.L external_functions_C.so
a = PtEtaPhiMVector(1,2,3,4)
testFunct(a)
(float) 1.00000f

so I think it must be something with how TTree::Draw is compiling the line.

[eguiraud]

Hi @jhowarth ,
not a direct answer to your question (sorry, for that I think we need @pcanal ) but RDataFrame has no problem handling arbitrary C++ types and your code above would be:

auto h = df.Define("pt_vec", "return Map(l_vec, [](PtEtaPhiMVector &l) { return l.Pt(); }")
           .Histo1D("pt_vec")

where arrays are read as RVec objects so we can use Map here to transform an array of PtEtaPhiMVectors into an array of floats.

More verbose, but also more versatile (and adding ROOT::EnableImplicitMT() in front automatically runs the query on multiple threads).

Cheers,
Enrico

[jhowarth]

Hi @eguiraud,

Thanks for the suggestion, but this would mean migrating a very large amount of code from TTree::Project setup to an RDataFrame setup. Which we would like to do eventually, but in the short term it’s not viable.

But thanks anyway for pointing out a longer-term solution!

Cheers,

Jay