Problem with type conversion for lorentz vector

Dear users,

I am writing a function with argument and return type ROOT::Math::PtEtaPhiMVector, defined as follows:

using namespace ROOT::Math;
TRandom2 *randvar = new TRandom2();
PtEtaPhiMVector smear_MET(ROOT::Math::PtEtaPhiMVector& MET, Double32_t N) {
    Double32_t mag = 1.*(randvar->Rndm());
    Double32_t angle = 2*M_PI*(randvar->Rndm());
    auto dpx = mag*cos(angle);
    auto dpy = mag*sin(angle);
    const PxPyPzEVector MET_P4(MET.Px()+dpx,MET.Py()+dpy,MET.Pz(),sqrt(pow((MET.Px()+dpx),2) + pow((MET.Py()+dpy),2) + pow(MET.Pz(),2)));
    const PtEtaPhiMVector MET_return(MET_P4.Pt(), MET_P4.Eta(), MET_P4.Phi(), 0);
    return MET_return;

This function I merge into my ROOT library with ROOT.gInterpreter.Declare and use it to define new branches of an RDataFrame object df as follows (python language):

df = df.Define('N',str(N))
df = df.Redefine('MET','smear_MET(MET, N)')
df = df.Define('mHT','ComputeMT4(L,MET,Jet1,Jet2)')

where the function ComputeMT4 takes 4 objects of type ROOT::Math::PtEtaPhiMVector as arguments. However, calling the latter function produces the following error:

Error in <TTreeReaderValueBase::CreateProxy()>: The branch Jet1 contains data of type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<Double32_t> >. It cannot be accessed by a TTreeReaderValue<ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<double> >>

To me it seems that there is an incompatibility between variables L, Jet1, Jet2 of type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<Double32_t> > and MET of type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<double> > .
Now, MET originally (without redefinition) also has type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<Double32_t> > and can be used without a problem in ComputeMT4(L,MET,Jet1,Jet2), but it is only after redefining it with smear_MET that it gets automatically converted to type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<double> >. My idea is to somehow force smear_MET to return an object of type ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<Double32_t> >, but trying to explicitly write the return type with Double32_t produces an error as well. Does anyone know how to solve this?

Hi @yburkard ,

sorry about the trouble! I’m not quite sure what’s going on. Can you please provide a small self-contained reproducer that I can take a look at?


Dear @eguiraud, thanks for your reply. Here is a small example with an attached file reproducing the error:
example_file.root (374.7 KB) (1.9 KB)
Let me know if you need anything else.


Thank you @yburkard , I can reproduce the problem.
I will debug as soon as possible and let you know what I find :slight_smile:


1 Like

This is now TTreeReader fails to read `T<Double_32>` as `T<double>` · Issue #12334 · root-project/root · GitHub : the root cause is a missing special-casing of template types that depend on Double32_t in TTreeReaderValue.

The issue description contains a patch that fixes your reproducer. Unfortunately before that patch becomes part of a release the only way to get that fix is compiler ROOT from source (after applying the patch, of course), and I do not have another workaround to suggest (other than changing the type of the column so it doesn’t use Double32_t until RDF/TTreeReader can deal with it, or not using RDF/TTreeReader).

Sorry I don’t have better news. This is a real, nasty bug! Thank you for reporting it!

cc: @Axel

1 Like

I wonder whether

TClass::GetClass("ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<Double32_t> >");


TClass::GetClass("ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<double> >");

called before the creation of the RDataFrame / opening of the file might be a work-around?

1 Like

TClass::GetClass("ROOT::Math::LorentzVector<ROOT::Math::PtEtaPhiM4D<double> >"); does the trick!

For @yburkard that’s


right before the creation of the dataframe in your

Thanks @Axel !

1 Like

Dear @Axel and @eguiraud, I just tried your suggestion and it worked perfectly! Thank you very much for your help! Re-installing ROOT or switching to another framework would have hindered my work significantly, so for now I will be sticking to this work-around :slight_smile:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.