We'd like to see if there's a good reason to require that the generator-level hadronic taus originate from not just any tau but from a prompt tau. Since the reconstructed taus are matched to the GenVisTau collection, and this collection has genPartIdxMother branch, we could in principle use the GenPart collection to pinpoint its mother particle (with PDG ID = +/- 15) and check its status flags.
The issue is somewhat complicated by the fact that we drop the GenPart collection from our Ntuples due to performance reasons, as it can sometimes include lots of objects to the point that we run out of memory. What we do have is a bunch of smaller gen particle collections, including a collection of generator-level taus (PDG ID = +/- 15) that are the last copies of itself in the Pythia decay chain. So, what we could do is to either:
take the GenVisTau particle that is matched to the reconstructed tau, and match it to GenTau:
update GenHadTau class such that we can assign mother particle to it, and query information about its prompt status;
introduce a flag (triggered on command line) that configures the analysis to read GenTau collection, match it to GenVisTau collection, and propagate the flag to getHadTauGenMatch that further restricts our definition of "a gen-matched hadronic tau" by requiring the reconstructed hadronic tau to be matched to a GenVisTau particle that itself descends from a generator-level prompt tau; OR
match GenTau directly to the reconstructed tau:
could be done explicitly or by reading TauGenMatch which corresponds to the tau from GenPart collection that is matched to the reconstructed tau at the NanoAOD-level (thanks @kramerto for the reminder);
unfortunately, it's not entirely clear to me how to efficiently propagate the status of TauGenMatch such that it's accessible by RecoHadTau (and ultimately by getHadTauGenMatch). Maybe adding RecoHadTau::assignGenMother(const std::vector<GenPart*> &) that saves the status flag of the matching mother particle works.
Regarding the last point, I learned that we should never use the by_index gen-matching option via command line, because the generator-level taus that are considered in the matching are not hadronic generator-level taus but taus that haven't decayed yet. Fortunately, none of the results we have produced thus far have this problem.
For testing, a few channels suffice, eg 0l+4tau and 2l+2tau in HH-multilepton. In the first approximation, we can ignore its effects on jet->tau FRs and just see how irreducible event yields are impacted by the change.
We'd like to see if there's a good reason to require that the generator-level hadronic taus originate from not just any tau but from a prompt tau. Since the reconstructed taus are matched to the
GenVisTaucollection, and this collection hasgenPartIdxMotherbranch, we could in principle use theGenPartcollection to pinpoint its mother particle (with PDG ID = +/- 15) and check its status flags.The issue is somewhat complicated by the fact that we drop the
GenPartcollection from our Ntuples due to performance reasons, as it can sometimes include lots of objects to the point that we run out of memory. What we do have is a bunch of smaller gen particle collections, including a collection of generator-level taus (PDG ID = +/- 15) that are the last copies of itself in the Pythia decay chain. So, what we could do is to either:GenVisTauparticle that is matched to the reconstructed tau, and match it toGenTau:GenHadTauclass such that we can assign mother particle to it, and query information about its prompt status;GenTaucollection, match it toGenVisTaucollection, and propagate the flag togetHadTauGenMatchthat further restricts our definition of "a gen-matched hadronic tau" by requiring the reconstructed hadronic tau to be matched to aGenVisTauparticle that itself descends from a generator-level prompt tau; ORGenTaudirectly to the reconstructed tau:TauGenMatchwhich corresponds to the tau fromGenPartcollection that is matched to the reconstructed tau at the NanoAOD-level (thanks @kramerto for the reminder);TauGenMatchsuch that it's accessible byRecoHadTau(and ultimately bygetHadTauGenMatch). Maybe addingRecoHadTau::assignGenMother(const std::vector<GenPart*> &)that saves the status flag of the matching mother particle works.Regarding the last point, I learned that we should never use the
by_indexgen-matching option via command line, because the generator-level taus that are considered in the matching are not hadronic generator-level taus but taus that haven't decayed yet. Fortunately, none of the results we have produced thus far have this problem.For testing, a few channels suffice, eg 0l+4tau and 2l+2tau in HH-multilepton. In the first approximation, we can ignore its effects on jet->tau FRs and just see how irreducible event yields are impacted by the change.