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
FillDescriptions for all 3 GsfElectronProducers #25574
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25574/7809 |
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. cms-bot commands are listed here |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
desc.add<edm::InputTag>("gsfElectronCoresTag",edm::InputTag("gsfElectronCores")) ; | ||
desc.add<edm::InputTag>("ecalDrivenGsfElectronsTag",edm::InputTag("ecalDrivenGsfElectrons")) ; | ||
desc.add<edm::InputTag>("pfMvaTag",edm::InputTag("pfElectronTranslator:pf")) ; | ||
desc.add<edm::InputTag>("gsfElectronCoresTag", edm::InputTag("gedGsfElectronCores")); |
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.
This was "gsfElectronCores"
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.
You should not compare this to the old commented-out fillDescriptions, but to the Python_cfi file:
https://github.com/cms-sw/cmssw/pull/25574/files#diff-6b9d40a5dde30255880f879f68bf9348L14
desc.add<bool>("checkHcalStatus", true); | ||
|
||
// output collections | ||
desc.add<std::string>("outputEGMPFValueMap", ""); |
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.
This is only in gedGsfElectronTmp
, but probably even useless, as it is never accessed in the code (if I am not wrong)
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 verify is "outputEGMPFValueMap" is really needed, and remove if not
desc.add<std::vector<int> >("recHitSeverityToBeExcludedBarrel") ; | ||
desc.add<std::vector<int> >("recHitSeverityToBeExcludedEndcaps") ; | ||
//desc.add<int>("severityLevelCut",4) ; | ||
desc.add<std::vector<std::string>>("recHitFlagsToBeExcludedBarrel", { |
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.
All these "RecHits...ToBeExcluded" were previously left undefined in this GsfElectronBaseProducer::fillDescription() and taken from centralized configurations in the actual cfi
recHitFlagsToBeExcludedBarrel = cleanedHybridSuperClusters.RecHitFlagToBeExcluded,
recHitFlagsToBeExcludedEndcaps = multi5x5BasicClustersCleaned.RecHitFlagToBeExcluded,
recHitSeverityToBeExcludedBarrel = cleanedHybridSuperClusters.RecHitSeverityToBeExcluded,
recHitSeverityToBeExcludedEndcaps = cleanedHybridSuperClusters.RecHitSeverityToBeExcluded,
I think that the same should be also done here (i.e. define them as above inside the actual cff files), in order to retain the possibility to modify them only once and centrally: do you agree?
{ | ||
edm::ParameterSetDescription psd0; | ||
{ | ||
edm::ParameterSetDescription psd1; |
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.
These isolation algo configs repeat themselves identically here inside every trkIsol03Cfg
\ trkIsol04Cfg
: it is easier to just fill the endcaps and barrel cuts with the same psd1
.
Moreover, in the previous config they were taken from the central RecoEgamma/EgammaIsolationAlgos/python/electronTrackIsolations_cfi.py
: as before, I think the same should be retained in the actual cff config here, so that it will be still possibile to modify all them centrally in one single place.
desc.add<std::string>("crackCorrectionFunction", "EcalClusterCrackCorrection"); | ||
|
||
desc.add<bool>("ecalWeightsFromDB", true); | ||
desc.add<std::vector<std::string>>("ecalRefinedRegressionWeightFiles", {}); // if not from DB. Otherwise, keep empty |
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.
This comment should be better added to the produced cfi, see
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideConfigurationValidationAndHelp#Adding_Comments
desc.add<bool>("ecalWeightsFromDB", true); | ||
desc.add<std::vector<std::string>>("ecalRefinedRegressionWeightFiles", {}); // if not from DB. Otherwise, keep empty | ||
desc.add<bool>("combinationWeightsFromDB", true); | ||
desc.add<std::vector<std::string>>("combinationRegressionWeightFile", {}); // if not from DB. Otherwise, keep empty |
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.
This comment should be better added to the produced cfi, see
https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideConfigurationValidationAndHelp#Adding_Comments
@@ -211,8 +297,8 @@ GsfElectronBaseProducer::GsfElectronBaseProducer( const edm::ParameterSet& cfg, | |||
strategyCfg_.addPflowElectrons = cfg.getParameter<bool>("addPflowElectrons") ; | |||
strategyCfg_.ctfTracksCheck = cfg.getParameter<bool>("ctfTracksCheck"); | |||
strategyCfg_.gedElectronMode = cfg.getParameter<bool>("gedElectronMode"); |
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.
This should also get defined in the base fillDescription...
(etc...)
In general: you removed from I think that only parameters which are specific of any derived class should be defined in the specialized fillDescription's, while anything is in common to all them, even if configured at run time with diferent face values in the different specializations, should be defined in the Base fillDescription, and only later modified in the actual python configs |
Hi Andrea, thanks for taking the time to review and discuss! I agree with what you said and that it should be in principal be done as you describe in the second paragraph of your general comment. However, I suspect that the most sustainable solution would involve rethinking this inheritance pattern of the GsfElectronProducers. What we have right now is 4 different producer classes (if you include the base class) which differ only slightly (order of 10 lines) in their How do you feel about that? |
@guitargeek , if I understand correctly your proposal you want to have eventually one single producer and the specializations will be configured via python config. That would be great, and the core of my comment goes exactly in that direction: you should centralize since now all possible common parameters in the base fillDescription, and specialize all residual differences in the dedicated python configs. |
Very well! Then let's go in this PR to the point where there is one single fillDescriptions for the defaults and 3 python configurations. The class unification will then follow eventually in a different PR I suppose. |
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25574/7923
|
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1
|
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, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
fillDescriptions()
to GsfElectronBaseProducer with defaultsOriginal, old blah blah:
Hi all,
between Christmas and new years I was thinking a bit about how some of our producers/algorithms are configured (in particular Egamma and PF producers). I noticed that configuration is often very verbose, repeating basically the same manual looping over configuration variables at several places, for example:
fillDescriptions
functionsAdditionally, there are repetitions from copy-pasted producers and their configs. Today I was trying to get rid of this redundancy at the example of the GsfElectronBaseProducer/GsfElectronAlgo combo, but didn't really conclude (ending up with some ugly preprocessor macros...). In any case, the first step would be to carry all the configuration over to C++ via the fillDescriptions functionality, which I propose in this PR, reducing some of the redundancy from the copy-pasted config files on the way.
Note that having all configuration defaults in the C++ code makes it easier to validate and therefor refactor things in the future, which I think eventually has to be done to reunite the upcoming low-pt electron reconstruction with the current reconstruction.
Local matrix tests pass and I hope I didn't do any mistakes shuffling config values around which cause differences!