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):
N=30.0
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?