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.

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

No need for GsfElectronCoreBaseProducer and merging .h and .cc files for EgammaElectronProducers #28746

Merged
merged 4 commits into from Jan 30, 2020
Merged

No need for GsfElectronCoreBaseProducer and merging .h and .cc files for EgammaElectronProducers #28746

merged 4 commits into from Jan 30, 2020

Conversation

guitargeek
Copy link
Contributor

PR description:

Now that #28429 is merged, it is the moment for a couple of more changes in RecoEgamma/ElectronProducers. One thing I'd like to address is the inheritance of plugins from "BaseProducers", which is something that I think sometimes awkwardly lies between plugin configuration and separate plugins. The GsfElectronCoreBaseProducer is one of these instances where it's probably not good to do it: the base producer just manages three products which are not even used by all inheriting producers and has a two-liner member function. Repeating this code in the inheriting producers is actually less verbose than having the base class, while making it clear which products are actually used and also making the transition to global modules easier.

Additionally, I apply several modernizations to the ElectronCore producers like the usage of edm::EDGetTokenT and also gave a similar treatment to the GEDGsfElectronFinalizer while at it.

PR validation:

CMSSW compiles and local matrix tests pass.

if this PR is a backport please specify the original PR:

No backport intended.

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28746/13379

  • This PR adds an extra 24KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @guitargeek (Jonas Rembser) for master.

It involves the following packages:

RecoEgamma/EgammaElectronProducers

@perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@Sam-Harper, @jainshilpi, @rovere, @lgray, @sobhatta, @afiqaize, @varuns23 this is something you requested to watch as well.
@davidlange6, @silviodonato, @fabiocos you are the release manager for this.

cms-bot commands are listed here

@slava77
Copy link
Contributor

slava77 commented Jan 15, 2020

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Jan 15, 2020

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/4241/console Started: 2020/01/15 23:27

}

event.put(std::move(electrons));
event.emplace(putToken_, electrons);
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to note that this will call the copy constructor of reco::GsfElectronCoreCollection inside emplace(). Using move like

event.emplace(putToken_, std::move(electrons));

would use the move constructor (that would be much cheaper for e.g. std::vectors).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @makortel for the heads up and taking care! I'm changing that of course.

@cmsbuild
Copy link
Contributor

+1
Tested at: 94eb010
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e814e7/4241/summary.html
CMSSW: CMSSW_11_1_X_2020-01-15-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e814e7/4241/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 34
  • DQMHistoTests: Total histograms compared: 2711715
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2711368
  • DQMHistoTests: Total skipped: 346
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
  • Checked 147 log files, 16 edm output root files, 34 DQM output files

@guitargeek guitargeek changed the title No need for GsfElectronCoreBaseProducer No need for GsfElectronCoreBaseProducer and merging .h and .cc files for EgammaElectronProducers Jan 16, 2020
@slava77
Copy link
Contributor

slava77 commented Jan 16, 2020

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Jan 16, 2020

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/4247/console Started: 2020/01/16 14:46

@cmsbuild
Copy link
Contributor

+1
Tested at: fdcbc69
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e814e7/4247/summary.html
CMSSW: CMSSW_11_1_X_2020-01-16-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e814e7/4247/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 34
  • DQMHistoTests: Total histograms compared: 2711715
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2711368
  • DQMHistoTests: Total skipped: 346
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
  • Checked 147 log files, 16 edm output root files, 34 DQM output files

@silviodonato
Copy link
Contributor

@perrotta @slava77 do you have further comments on this PR?

@silviodonato
Copy link
Contributor

This is just a friendly reminder for @slava77 and @perrotta

#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h"
#include "DataFormats/ParticleFlowReco/interface/GsfPFRecTrack.h"
#include "DataFormats/GsfTrackReco/interface/GsfTrack.h"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are you removing these include's? Are you relying on them being included through GsfElectronCore.h?
I would personally further add GsfTrackFwd.h, for completeness.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Again, correct me if I'm wrong, but I think these *Fwd.h are not meant to be included in *.cc files, and that's why I removed them. Indeed, I'm relying here on the indirect include via GsfElectronCore.h which I think is fine because the *Track objects in this producer are only used as arguments for GsfElectronCore constructors or member functions, so we can rely on GsfElectronCore.h to have the good typedefs imported to use it's own functions. Is that OK for you?

#include "CommonTools/CandAlgos/interface/ModifyObjectValueBase.h"
#include "DataFormats/Common/interface/ValueMap.h"
#include "DataFormats/EgammaCandidates/interface/GsfElectron.h"
#include "DataFormats/ParticleFlowCandidate/interface/PFCandidate.h"
Copy link
Contributor

Choose a reason for hiding this comment

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

What about

#include "DataFormats/EgammaCandidates/interface/GsfElectronFwd.h"
#include "DataFormats/ParticleFlowCandidate/interface/PFCandidateFwd.h"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

GsfElectronFwd.h is already correctly imported in GsfElectron.h and PFCandidateFwd.h is already correctly imported in PFCandidate.h.

#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h"
#include "DataFormats/ParticleFlowReco/interface/GsfPFRecTrack.h"
#include "DataFormats/GsfTrackReco/interface/GsfTrack.h"
#include "DataFormats/EgammaReco/interface/SuperClusterFwd.h"
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are these two include's removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The include of ElectronSeedFwd.h is removed because this is already correctly included in ElectronSeed.h. The SuperCluster include is removed because again it's a Fwd and we only use the reco::SuperClusterRef as an argument for one of the member functions in GsfElectronCore [1]. So again I think it's fair to get this definition indirectly via GsfElectronCore.h.

[1] https://github.com/cms-sw/cmssw/blob/master/DataFormats/EgammaCandidates/interface/GsfElectronCore.h#L55

if (!eleCore->ecalDrivenSeed()) {
delete eleCore;
if (!eleCore.ecalDrivenSeed()) {
electrons.pop_back();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not checking first if gsfTrackRef.ecalDrivenSeed(), and then emplace_back only in that case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, but it turns out the GsfTrack does not have this member function, so one would have to reproduce the logic from the GsfElectronCore producer I think [1]. I'm not really sure that we can find a quick and safe solution without code duplication in the scope of this PR, or do you have any idea?

[1] https://github.com/cms-sw/cmssw/blob/master/DataFormats/EgammaCandidates/src/GsfElectronCore.cc#L15

@@ -1,62 +1,79 @@
#include "DataFormats/EgammaCandidates/interface/GsfElectronCore.h"
#include "DataFormats/EgammaCandidates/interface/GsfElectronCoreFwd.h"
Copy link
Contributor

Choose a reason for hiding this comment

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

Still missing the point why these includes are removed, as well as SuperClusterFwd.h

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Someone correct me if I'm wrong, but here is the line of thought I had:

In general, the point of forward declarations is to keep header files light. This LowPtGsfElectronCoreProducer.cc is not a header file and therefore the actual GsfElectronCore.h is needed instead of GsfElectronCoreFwd.h. This makes GsfElectronCoreFwd.h superfluous because it's already included in GsfElectronCore.h [1], like it should be to get the typedefs.

[1] https://github.com/cms-sw/cmssw/blob/master/DataFormats/EgammaCandidates/interface/GsfElectronCore.h

@perrotta
Copy link
Contributor

Thank you @guitargeek for checking.

About the inclusion of header files: I think to remember that it was recommended to include in every package the headers of all classes needed internally, to avoid troubles in case the header nesting the needed ones got changed. (In our case this doesn't even apply, because as you correctly point out, the same definitions are repeated in the non-forward declared header).
Moreover, I don't find that rule coded anywhere for CMS [1]: therefore I won't insist on it

[1] http://cms-sw.github.io/cms_coding_rules.html

@perrotta
Copy link
Contributor

+1

  • Electron producers in RecoEgamma/EgammaElectronProducers are simplified, by removing the intermediate layer of a base producer, as well as by applying other code modernization in them
  • Jenkins test pass and show no difference with the baseline

@cmsbuild
Copy link
Contributor

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. @davidlange6, @silviodonato, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

@silviodonato
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants