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
Fix PUPPI MET tails #17072
Fix PUPPI MET tails #17072
Conversation
A new Pull Request was created by @ahinzmann for CMSSW_9_0_X. It involves the following packages: CommonTools/PileupAlgos @cmsbuild, @cvuosalo, @slava77, @monttj, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
@@ -31,17 +31,19 @@ PuppiPhoton::PuppiPhoton(const edm::ParameterSet& iConfig) { | |||
tokenPFCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("candName")); | |||
tokenPuppiCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("puppiCandName")); | |||
tokenPhotonCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("photonName")); | |||
tokenPhotonId_ = consumes<edm::ValueMap<bool> >(iConfig.getParameter<edm::InputTag>("photonId")); | |||
reco2pf_ = mayConsume<edm::ValueMap<std::vector<reco::PFCandidateRef> > >(iConfig.getParameter<edm::InputTag>("recoToPFMap")); |
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.
please change to consumes according to the value of runOnMiniAOD.
The current implementation has no alternatives if runOnMiniAOD is false.
@@ -31,17 +31,19 @@ PuppiPhoton::PuppiPhoton(const edm::ParameterSet& iConfig) { | |||
tokenPFCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("candName")); | |||
tokenPuppiCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("puppiCandName")); | |||
tokenPhotonCandidates_ = consumes<CandidateView>(iConfig.getParameter<edm::InputTag>("photonName")); | |||
tokenPhotonId_ = consumes<edm::ValueMap<bool> >(iConfig.getParameter<edm::InputTag>("photonId")); | |||
reco2pf_ = mayConsume<edm::ValueMap<std::vector<reco::PFCandidateRef> > >(iConfig.getParameter<edm::InputTag>("recoToPFMap")); | |||
tokenPhotonId_ = mayConsume<edm::ValueMap<bool> >(iConfig.getParameter<edm::InputTag>("photonId")); |
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.
please change to consumes based on the value of usePhotonId.
Actually, if photonId is empty, the framework will already ignore the consumes
const pat::Photon *pPho = dynamic_cast<const pat::Photon*>(&(*itPho)); | ||
if(pPho != 0) { | ||
for( const edm::Ref<pat::PackedCandidateCollection> & ref : pPho->associatedPackedPFCandidates() ) { | ||
if(fabs(pfCol->ptrAt(ref.key())->eta()) < eta_ ) { |
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.
some comments would be useful to say that for "runOnMiniAOD" the pfCol is supposed to be a packedcandidate collection.
Better yet, use ref directly, since unless pfCol->ptrAt(ref.key())
points to the same object as ref
, there is a problem.
} | ||
} else { | ||
for( const edm::Ref<std::vector<reco::PFCandidate> > & ref : (*reco2pf)[phoCol->ptrAt(iC)] ) { | ||
if(fabs(pfCol->ptrAt(ref.key())->eta()) < eta_ ) { |
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.
here again it looks like pfCol->ptrAt(ref.key())
should be replaced with ref
, else this opens up a way for inconsistencies
Here are some comparisons on top of #17067 HGG PU35, in the standard AOD->MINIAOD workflow since the genMET is essentially zero, the diff with genmet shows an increase in the over-measured values e.g. the slice of MET 80 to 100 more than doubles in population I'm guessing it's the ID cuts which are now applied ZEE PU35 and TTbar PU35 do not have a significant change. ============= so, this PR makes PUPPI MET worse for events with photons. Looking at the fix referenced in the slides The slides suggest that puppiMET is remade from miniAOD inputs. Please make some plots comparing puppiMET made from AOD and that made from miniAOD. |
…rom AOD and MiniAOD more similar
@slava77 I implemented the comments and did a comparison of running on AOD and MiniAOD. Starting from 1000 event in The MET value when running on AOD and MiniAOD agrees within 1% for all events. For example, the first couple of events differ like this: < PUPPI MET: pt 8.1
So the behavior you observe does not come from AOD/MiniAOD differences. I also doubt it comes from the photon ID, since everything was tested with the Spring15 photon ID that is also in CMSSW_9_0_0. The change of the METRecipe_8020_Moriond17 recipe to the Spring16 photon ID only happened recently with the new Moriond recommendations. Do you think you could check one more plot, to confirm that this PR achieves its main purpose, that is removing the MET tails in QCD events as shown on slide 3 of https://indico.cern.ch/event/587258/contributions/2366495/attachments/1368938/2117761/satoshi_updatedAfterTheMeeting.pdf |
On 1/6/17 1:57 PM, ahinzmann wrote:
Do you think you could check one more plot, to confirm that this PR
achieves its main purpose, that is removing the MET tails in QCD events
as shown on slide 3 of
https://indico.cern.ch/event/587258/contributions/2366495/attachments/1368938/2117761/satoshi_updatedAfterTheMeeting.pdf
A plot of the MET in log-y-scale in a flat (or high pT) QCD sample
should show this.
It could be possible that getting rid of these tails trades off with
some performance loss in the gamma gamma MET.
I can check in the QCD sample, but mostly likely not until Monday,
possibly during the weekend.
Just to be more specific on the sample:
which sample is used in p3?
The text says "flat QCD (MiniAOD one file)."
Is there PU in this sample?
p5 has
/QCD_Pt-15to7000_TuneCUETP8M1_Flat_13TeV_pythia8/RunIISummer16MiniAODv2-PUFlat0to70_magnetOn_80X_mcRun2_asymptotic_2016_TrancheIV_v4-v1/MINIAODSIM
with pileup
Was it this sample?
|
@slava77 confirmed. The 0-70 PU sample. (Though PU is not the source of the tails, thus the MET tails should show up in any flat/high pT QCD samples) |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Here is a diff for 25209.0 miniAOD (from RECO /RelValQCD_FlatPt_15_3000HS_13/CMSSW_9_0_0_pre2-PU25ns_90X_mcRun2_asymptotic_v0-v1/GEN-SIM-RECO ) clearly, there is a reduction of large tails. So, the Hgammagamma plots I posted earlier are also consistent. @ahinzmann |
This contains 2 fixes needed to remove tails of the PUPPI MET distribution:
The impact of this PR on jet and MET response and resolution has been validated.
Slide 17-22 show the impact of this change to MET:
https://indico.cern.ch/event/587258/contributions/2366495/attachments/1368938/2117761/satoshi_updatedAfterTheMeeting.pdf
What is labeled v10 is in the CMSSW_8_0_>=20 and CMSSW_8_1_X and CMSSW_9_0_X releases at the moment.
What is labeled "PFPUPPI v10 PHfix wgtRecal" is in this PR.
This PR changes the MINIAOD PUPPI MET collection, no changes to RECO/AOD event content.