-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Remove noisy missing collection warnings coming from EcalDQMonitorTask #42848
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-42848/36978
|
A new Pull Request was created by @alejands (Alejandro Sanchez) for master. It involves the following packages:
@nothingface0, @emanueleusai, @cmsbuild, @pmandrik, @syuvivida, @tjavaid, @micsucmed, @rvenditti can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
test parameters:
|
@cmsbuild, please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e6c161/34874/summary.html Comparison SummarySummary:
GPU Comparison SummarySummary:
|
The remaining
|
please test with #42844 |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e6c161/34894/summary.html Comparison SummarySummary:
GPU Comparison SummarySummary:
|
The remaining warnings are gone now (log). |
+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. @rappoccio, @antoniovilela, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Addresses issue #42720 dealing with multiple missing collection warnings per event coming from the
EcalDQMonitorTask
module using theecalMonitorTaskEcalOnly
config in offline relval WFs. The collections fell into one of three groups with each group having a separate reason or set of reasons for the warnings.The
GpuRecHit
collections do not exist (as far as I know this is still the case). RecHit monitoring was switched off for online GPU validation in #39393, but this was not propagated to offline since RecHits were enabled by default in the ECAL GPU validation module. With this PR, the RecHits will now be switched off by default. The assumed RecHit input tags are already in place for when the collections are implemented.In addition, there was an oversight of mine in #39371 while implementing these collection-level switches to be used in exactly this kind of context. This is now corrected in this PR, and unused collections for GPU monitoring are no longer consumed.
The
TrigPrimEmulDigi
andReducedRecHit
collections are straightforward to explain. They are not being produced in offline DQMEcalOnly
workflows, and there are already flags in place to switch off running over these collections. The emulated digis were already switched off in the general offline config, but the same was not done for theEcalOnly
config, as the collection is switched off after cloning the original config. This PR switches these collections off for the offlineEcalOnly
config.EcalRawData
is the trickiest to switch off on the ECAL DQM side since it's used by several modules. This issue is now resolved in #42844.However, we simultaneously implemented a bandaid solution on the ECAL DQM side. We added a parameter to
EcalDQMonitorTask
calledskipCollections
that takes in the names of collections to be explicitly removed from the list of collections being run by the ECAL DQM module.The skipping is done as barebones as possible and we decided to purposefully not remove any dependencies that might cause a problem if a collection is not present. This way we can prevent potentially undefined behavior from slipping through the cracks and leaving little to no trace of something being wrong.
Skipping a collection will lead to the same behavior as having a missing collection if there is a further issue. The difference is that a skipped collection will not be consumed and the ECAL DQM module will not attempt to access the data. This could be useful in the future and not necessarily in the context of a missing collection.
The other PR is the ideal solution to the current issue so this isn't going to be used right now, but it doesn't hurt to have the extra customizability option in our toolkit.
PR validation:
Tested with both workflows brought up in issue #42720. The workflows ran successfully with no warnings.
Adding
EcalRawData
to the newskipCollections
parameter works as intended. The warning and exception paths added also run as intended in their relevant scenarios.If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
A backport can be made if needed.