-
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
renew matched lepton ids for every jet #41325
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-41325/35148
|
A new Pull Request was created by @menglu21 (Meng_Lu) for master. It involves the following packages:
@cmsbuild, @simonepigazzini, @swertz, @vlimant can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@@ -91,6 +91,8 @@ void LeptonInJetProducer<T>::produce(edm::StreamID streamID, edm::Event &iEvent, | |||
fastjet::PseudoJet p(d->px(), d->py(), d->pz(), d->energy()); | |||
lClusterParticles.emplace_back(p); | |||
} | |||
ele_pfmatch_index = -1; |
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 two variables can be created here, removing the definitions lines 79-80
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.
I prefer the current one since define the variables every time in the loop may use more memory, though the difference could be small since they are "int".
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.
I think optimization this is not an issue, and actually it ensures that the variables goes out of scope once the loop is compelted. Anyway I'll let the release manages commenting on this.
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.
I think optimization this is not an issue, and actually it ensures that the variables goes out of scope once the loop is compelted. Anyway I'll let the release manages commenting on this.
Since you are asking, I think that having a variable defined in a as small as possible scope is normally an advantage. In any case, it is a minor issue here, and I'd let you decide what you prefere for it.
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.
update to what @simonepigazzini suggested
This indeed looks like a bug. Still could you please provide more details concerning the validation (sample used, expected number of jets/ele, etc). Thank you |
The sample I used for check is /store/mc/RunIISummer20UL17MiniAODv2/NMSSM_XToYHTo2Z2BTo2L2J2B_MX-2000_MY-600_TuneCP5_13TeV-madgraph-pythia8/MINIAODSIM/106X_mc2017_realistic_v9-v2/50000/0C182B07-16FE-004A-8CAE-BB94CD140219.root, sorry but I don't understand "expected number of jet/ele", the number should not change, only the information of jet-ele matching is affected |
I mean if you expected or not to have an ele/jet matching at all, and if so how many are expected. |
the information should be useful anyway, I'm not sure how many match should be stored, currently only the closest ele is stored for every fatjet, it could be more. If all the matched information are stored then that's great, but it need some design on the output tree |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-41325/35153
|
Pull request #41325 was updated. @cmsbuild, @simonepigazzini, @swertz, @vlimant can you please check and sign again. |
I was going through the logic here again: https://github.com/cms-sw/cmssw/pull/41325/files#diff-667e23cfcc737cc2ceb2f59eddcdc74a19d2c21bd11fea5e02c09d3944626eb6R96 If a matched muon is found, the electron index is reset to -1 -> it looks like it's because the idea is to store only the lepton that is used in the The matching logic is anyway a bit strange, e.g. an electron with dR(j,e)=0.3 and pT=10 GeV is given priority over a muon with dR(j,mu)=0.31 and pT=100 GeV... |
enable nano |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-50a5c7/32102/summary.html Comparison SummarySummary:
NANO Comparison SummarySummary:
Nano size comparison Summary:
|
+1 |
@menglu21 can you please open a backport for 13_0_X |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
sure, will do it soon |
PR description:
< initially the matched lepton ids are declared only once https://github.com/cms-sw/cmssw/blob/master/PhysicsTools/NanoAOD/plugins/LeptonInJetProducer.cc#L79-L80, in the case of that when there is no matched lepton, the previous matched lepton id will be used for the next jet, i.e., two fat jets can match to one lepton which is not correct. >
PR validation:
<before the modification:
after the modification:
you see that before modification, for the first event, the first and second fatjet match to the first lepton. similar case in 6th event. (the pt of jet is to confirm other info is not changed )