separate token for the view #5114
Conversation
|
A new Pull Request was created by @slava77 (Slava Krutelyov) for CMSSW_7_2_X. separate token for the view It involves the following packages: CommonTools/ParticleFlow @nclopezo, @monttj, @cmsbuild, @StoyanStoynev, @slava77, @vadler can you please review it and eventually sign? Thanks. |
|
+1 |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes or unless it breaks tests. |
| @@ -19,6 +19,8 @@ PFPileUp::PFPileUp(const edm::ParameterSet& iConfig) { | |||
|
|
|||
| tokenPFCandidates_ | |||
| = consumes<PFCollection>(iConfig.getParameter<InputTag>("PFCandidates")); | |||
| tokenPFCandidatesView_ | |||
| = mayConsume<PFView>(iConfig.getParameter<InputTag>("PFCandidates")); | |||
There was a problem hiding this comment.
@slava77 - seems that the proper change here is
if (enable_)
tokenPFCandidates_ = consumes….
else
tokenPFCandidatesView_ = consumes …..
[as it is, the first consumes statement is not always right unless I've missed something]
There was a problem hiding this comment.
What's the enable_?
If your point is to pick only one at the config step, that's not what the
code was designed to implement.
If thats an issue, current state of use cases is such that the second
branch using a view can be removed completely
On Aug 30, 2014 8:00 AM, "David Lange" notifications@github.com wrote:
In CommonTools/ParticleFlow/plugins/PFPileUp.cc:
@@ -19,6 +19,8 @@ PFPileUp::PFPileUp(const edm::ParameterSet& iConfig) {
tokenPFCandidates_
= consumes(iConfig.getParameter("PFCandidates"));
- tokenPFCandidatesView_
- = mayConsume(iConfig.getParameter("PFCandidates"));
@slava77 https://github.com/slava77 - seems that the proper change here
isif (enable_)
tokenPFCandidates_ = consumes….
else
tokenPFCandidatesView_ = consumes …..[as it is, the first consumes statement is not always right unless I've
missed something]—
Reply to this email directly or view it on GitHub
https://github.com/cms-sw/cmssw/pull/5114/files#r16929566.
There was a problem hiding this comment.
enable_ is at line 28 (just below this change)
I thought I read
if enable_ use PFCandidates
if not enable_ use PFView
if I got that wrong, then i'm just creating noise.
There was a problem hiding this comment.
It looks to me like both consumes are dependent upon enable_ being true. I think the confusion in the code is the long comment between the end of the if statement and the beginning if the else statement.
There was a problem hiding this comment.
right, the enable_ is about all of the consumes in this module .. if false, nothing is read and an empty product is inserted in the event.
The code is designed to solve the framework problem of not being able to deliver a view out of a collection of pointers. Since the output is a collection of pointers, the input can interchangeably be the parent object collection or a collection of pointers made out of them at a different place ( it could technically be even changing event by event, not that it is the use case now)
There was a problem hiding this comment.
@Dr15Jones
Chris, if I say "consumes" or "mayConsume" for a product that doesn't exist (that's the case for my mayConsume here), what are the implications on the framework side?
In the current default 72X setup the code runs ok, or if there is a miss it fails on the event itself (not before event processing starts).
There was a problem hiding this comment.
If the product doesn't exist at all, you will fail when doing the get just like the case without the consumes.
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
…n418/PFPileUp-fix Separate token for the view
use a token with correct type for the fall-back case of using a candidate view as an input.