-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
use esConsumes in PhysicsTools/PatAlgos modules #34997
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34997/24852
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages:
@jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
Given that these functions do not seem to provide anything beyond cmssw/JetMETCorrections/Modules/src/JetResolution.cc Lines 23 to 28 in 00ca4ca
I have elsewhere just replaced their use with direct use of EventSetup::getData() in the calling code.
|
That is what I was thinking, but I figured I'd want to do it systematically and then remove the interface. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6dbb72/18002/summary.html Comparison SummarySummary:
|
I should have looked closer, TrackDetectorAssociator was already updated for esConsumes. |
Instead, just get data directly from the EventSetup using the proper esConsumes.
I went ahead and removed the |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-34997/24859
|
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6dbb72/18009/summary.html Comparison SummarySummary:
|
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, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
void pat::PATJetSlimmer::produce(edm::Event& iEvent, const edm::EventSetup& iSetup) { | ||
using namespace edm; | ||
using namespace std; | ||
|
||
if (modifyJet_) | ||
jetModifier_->setEventContent(iSetup); |
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.
It was evidently done on purpose, and therefore I can imagine the answer: but is it really convenient calling this method once per event, instead of once per LuminosityBlock
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 transition for the get call is set at compile time in the call to esConsumes
. Making helper classes (which can be used by multiple modules) have different consumes for different modules is pretty annoying and error prone. Plus, getting data from the EventSetup is VERY fast (and so we recommend always getting it in the transition it is used as long as no further big computation is done with it).
+1 |
PR description:
Converted all modules to use missing esConsumes.
PR validation:
Code compiles.