The MC-matching of recostructed hadronic taus to generator-level particles is already performed during NanoAOD production. The match is indicated by two variables: Tau_genPartFlav and Tau_genPartIdx. The former is an integer that tells whether the reconstructed hardonic tau is matched to a prompt electron (1), a prompt muon (2), an electron from tau decay (3), a muon frmo tau decay (4), a hadronic tau decay product (5) or not matched to anything at all (0), while the latter points to gen tau with absolute PDG ID 15 in GenPart collection with Pythia status equal to 2. However, I'm noticing that the index branch doesn't seem to be reliable when genPartFlav is equal to 5, since it's set to 0 (ie to a valid index to an incorrect match) for the most part.
Additionally in our code we find the actual generator-level particle that is matched to the reconstructed hadronic tau:
https://github.com/HEP-KBFI/TallinnNtupleProducer/blob/68d8726012983824ed6d71843b23e6dd98f044da/Readers/src/EventReader.cc#L583-L588
Doing the dR-matching between reconstructed hadronic taus and generator-level hadronic taus (and jets) is strictly not necessary because the genPartFlav attribute should be enough for our purposes, unless we want to include tau charge flips when estimating charge flip background.
AFAICT, the generator-level taus that are considered in the matching are not necessarily coming from prompt taus, even though we claim that they are. For example, the only reconstructed tau in event 174487533 in this QCD sample [*] has genPartFlav equal to 5, but comes from quark hadronization. The purpose of this issue is to assess how big of a deal this really is, and possibly make a proposal to XPOG or Tau POG if we find anything significant. (This issue is a duplicate of https://github.com/HEP-KBFI/tth-htt/issues/178, but the analysis conditions have changed.)
The MC-matching of recostructed hadronic taus to generator-level particles is already performed during NanoAOD production. The match is indicated by two variables:
Tau_genPartFlavandTau_genPartIdx. The former is an integer that tells whether the reconstructed hardonic tau is matched to a prompt electron (1), a prompt muon (2), an electron from tau decay (3), a muon frmo tau decay (4), a hadronic tau decay product (5) or not matched to anything at all (0), while the latter points to gen tau with absolute PDG ID 15 inGenPartcollection with Pythia status equal to 2. However, I'm noticing that the index branch doesn't seem to be reliable whengenPartFlavis equal to 5, since it's set to 0 (ie to a valid index to an incorrect match) for the most part.Additionally in our code we find the actual generator-level particle that is matched to the reconstructed hadronic tau: https://github.com/HEP-KBFI/TallinnNtupleProducer/blob/68d8726012983824ed6d71843b23e6dd98f044da/Readers/src/EventReader.cc#L583-L588 Doing the dR-matching between reconstructed hadronic taus and generator-level hadronic taus (and jets) is strictly not necessary because the
genPartFlavattribute should be enough for our purposes, unless we want to include tau charge flips when estimating charge flip background.AFAICT, the generator-level taus that are considered in the matching are not necessarily coming from prompt taus, even though we claim that they are. For example, the only reconstructed tau in event
174487533in this QCD sample [*] hasgenPartFlavequal to 5, but comes from quark hadronization. The purpose of this issue is to assess how big of a deal this really is, and possibly make a proposal to XPOG or Tau POG if we find anything significant. (This issue is a duplicate of https://github.com/HEP-KBFI/tth-htt/issues/178, but the analysis conditions have changed.)[*]
/store/mc/RunIIAutumn18NanoAODv7/QCD_Pt_80to170_bcToE_TuneCP5_13TeV_pythia8/NANOAODSIM/Nano02Apr2020_102X_upgrade2018_realistic_v21-v1/100000/EEA6BD5C-1ADC-2248-9B71-886117460EA5.root