Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Ecal DPG - Deploy new software (based on BDT) to recover isolated dead channels… #27175
Ecal DPG - Deploy new software (based on BDT) to recover isolated dead channels… #27175
Changes from 5 commits
b7d7959
58ca071
da9d251
ec9e102
155b8aa
edab6bc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm missing the reason why the first argument is needed.
It looks vestigial.
Please remove or clarify why needed.
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.
In a way it's vestigial because it was used when the two recovery algorythms were coexisting. Although we have decided to throw away the NN, we do not want to remove the possibility for a future to include an other algo
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.
but what would be the reason to keep it here, after the choice of the algo is made?
Even in the older variant of the code where both NN and BDTG were (unnecessarily) instantiated together there was still an assumption that only one of them can run.
If you really need it, the choice of the algo should be done when the EcalDeadChannelRecoveryAlgos is constructed, not in this method.
So, I do not see a reason for the algo parameter here.
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 choice is made in https://github.com/nancymarinelli/cmssw/blob/deadChannelRecoveryBDT_V1/RecoLocalCalo/EcalRecProducers/plugins/EcalRecHitWorkerRecover.cc#L127 and the setCaloToplogy is necessary to pass the topology to the chosen algo. At this point in time, and with all the ifs related to the main validation, we do not certainly feel to make any change to how the framework was setup
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.
right, I know this point of entry for the topology.
My comment still stands.
the choice of the algorithm is already made earlier (in
ebDeadChannelCorrector.setParameters(ps)
) there is no reason or a reasonable way to modify it here event by event.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 looks like the two methods above are not needed (defaults will be created by the compiler anyways)
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.
Do they make any harm ? I personally like to have them explicit there
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 compiler is actually a good buddy of us! For example, when the destructor is compiler-generated, it is implicitly declared as
noexcept
which is one of the recommendations in the C++ Core Guidelines.Edit: should have read the guidelines more carefully before posting... Just realized the same implicit
noexcept
goes for user-defined destructors too. Okay then this was not a good argument :)