Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promptness of reconstructed hadronic tau #23

Open
ktht opened this issue Aug 1, 2022 · 0 comments
Open

Promptness of reconstructed hadronic tau #23

ktht opened this issue Aug 1, 2022 · 0 comments

Comments

@ktht
Copy link
Member

ktht commented Aug 1, 2022

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:

if ( isUpdatedHadTaus )
{
hadTauGenMatcher_->addGenMatchByIdx(event_.hadTau_ptrs_, event_.genParticles_);
hadTauGenMatcher_->addGenHadTauMatch(event_.hadTau_ptrs_, event_.genHadTaus_);
hadTauGenMatcher_->addGenJetMatch(event_.hadTau_ptrs_, event_.genJets_);
}

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.)

[*] /store/mc/RunIIAutumn18NanoAODv7/QCD_Pt_80to170_bcToE_TuneCP5_13TeV_pythia8/NANOAODSIM/Nano02Apr2020_102X_upgrade2018_realistic_v21-v1/100000/EEA6BD5C-1ADC-2248-9B71-886117460EA5.root

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant