You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 HEP-KBFI/tth-htt#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_genPartFlav
andTau_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 inGenPart
collection with Pythia status equal to 2. However, I'm noticing that the index branch doesn't seem to be reliable whengenPartFlav
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:
TallinnNtupleProducer/Readers/src/EventReader.cc
Lines 583 to 588 in 68d8726
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 [*] hasgenPartFlav
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 HEP-KBFI/tth-htt#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
The text was updated successfully, but these errors were encountered: