-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Make jets in TauGenJetProducer from taus which are not decayed #41064
Conversation
Meant to fix #37169. |
please test |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-41064/34665
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages:
can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e98468/31300/summary.html Comparison SummarySummary:
|
Thank you @Dr15Jones to provide a possible fix fur such a long standing issue. The main issue seems to me reside in the generators which do not decay those taus: was it done on purpose (i.e. long lived)? In that case, an alternative could be to add the undecayed tau itself to the jet, i.e. if (descendents.empty()) {
edm::LogWarning("NoTauDaughters") << "Tau p4: " << (*iTau)->p4() << " vtx: " << (*iTau)->vertex()
<< " has no daughters: the tau itself is added to the TauGenJet";
charge += (*iTau)->charge();
sumVisMom += (*iTau)->p4();
constituents.push_back(refToPtr(*iTau));
continue;
} If so, this should go after the check on the status 2 taus, and of course after the definition of @cms-sw/tau-pog-l2 what do you think? |
Hi, I prefer to ask a few things before to greenlight this. I remember too that some generators make taus decay into themselves, and at the end of the cascade the final tau is decayed. |
@alebihan in case your question refers to my proposed alternative to this PR:
|
Can you please share a recipe to see the crash? @mbluj @Ksavva1021 @danielwinterbottom what do you think? |
I think that is generally better to keep pathological entries than exclude them. However, it is good to add information which will allow easily identify them to enable its simple filtering or selection (depending on use-case). One can use for this purpose the |
@perrotta wrote
So from the log of the failed job, the exception message showed that the taus have very large momentum such that the relativistic gamma factor times the half life of the tau gives a length greater than the distance to the beam pipe. That condition exceeds the threshold we've told Pythia to decay the taus (since the tau could interact with material and therefore should be handled by Geant). So I would not classify this as a pathological case, just a rare 'edge' case. |
Ok, great! |
So, for me it makes even more sense to keep tauJets for such taus. |
So the tauGenJets would have a special flag to track them, contain the p4 of the undecayed tau (full p4 with neutrino), and the crash would be avoided. Makes sense, thanks. |
@Dr15Jones how we can proceed? Could you add genTauJets for the undecayed taus as proposed by @perrotta and then I will prepare a followup PR with |
Instead of creating a dummy empty jet, taus which were not decayed by the generator are now used to create a jet based on the tau's own data. This avoids failures in the integration builds.
b5b3171
to
bbd0d87
Compare
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-41064/34684
|
please test |
@@ -41,6 +40,20 @@ void TauGenJetProducer::produce(edm::StreamID, Event& iEvent, const EventSetup& | |||
GenParticleRefVector descendents; | |||
findDescendents(*iTau, descendents, 1); | |||
|
|||
if (descendents.empty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The taus causing the problem were never in the descendants, they always came from the main list.
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e98468/31328/summary.html Comparison SummarySummary:
|
Looks good as far as I can see. So these taus are always HEPMC status 1 as not decayed on purpose? |
It is fine with me. I will follow with "status PR" when this one is merged. |
+1
|
merge |
Even after the merge of this PR there are still instances of the error
See integration builds of CMSSW_13_1_X_2023-03-19-0000, namely wf 148.0 in el8_amd64_gcc11 |
The issue is caused by this piece of code of
I think that it will be best that this is decided and then implemented by owners of the code, but I can also do it if useful (I would opt for solution 2.). |
PR description:
Instead of creating a dummy empty jet, taus which were not decayed by the generator are now used to create a jet based on the tau's own data. This avoids failures in the integration builds.
Did some minor code cleanups.
PR validation:
Code compiles.