Skip to content
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.

Sign up for GitHub

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

Jump to bottom

separate token for the view #5114

Merged
merged 1 commit into from Sep 1, 2014
Merged

separate token for the view #5114

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 3 additions & 1 deletion CommonTools/ParticleFlow/plugins/PFPileUp.cc
View file
Open in desktop
Expand Up @@ -19,6 +19,8 @@ PFPileUp::PFPileUp(const edm::ParameterSet& iConfig) {

tokenPFCandidates_
= consumes<PFCollection>(iConfig.getParameter<InputTag>("PFCandidates"));
tokenPFCandidatesView_
= mayConsume<PFView>(iConfig.getParameter<InputTag>("PFCandidates"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
is

if (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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the product doesn't exist at all, you will fail when doing the get just like the case without the consumes.


tokenVertices_
= consumes<VertexCollection>(iConfig.getParameter<InputTag>("Vertices"));
Expand Down Expand Up @@ -87,7 +89,7 @@ void PFPileUp::produce(Event& iEvent,
// then we can pass it to the PFPileupAlgo.
else {
Handle<PFView> pfView;
bool getFromView = iEvent.getByToken( tokenPFCandidates_, pfView );
bool getFromView = iEvent.getByToken( tokenPFCandidatesView_, pfView );
if ( ! getFromView ) {
throw cms::Exception("PFPileUp is misconfigured. This needs to be either vector<FwdPtr<PFCandidate> >, or View<PFCandidate>");
}
Expand Down
2 changes: 2 additions & 0 deletions CommonTools/ParticleFlow/plugins/PFPileUp.h
View file
Open in desktop
Expand Up @@ -50,6 +50,8 @@ class PFPileUp : public edm::stream::EDProducer<> {

/// PFCandidates to be analyzed
edm::EDGetTokenT<PFCollection> tokenPFCandidates_;
/// fall-back token
edm::EDGetTokenT<PFView> tokenPFCandidatesView_;

/// vertices
edm::EDGetTokenT<reco::VertexCollection> tokenVertices_;
Expand Down