-
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
fixing obsolete EDAnalyzer in DQM/BeamMonitor #37071
Conversation
assign alca |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37071/28535
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
addresses part of #36404 |
There's an earlier attempt from @francescobrivio at #35501. We've been wondering if a |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37071/28536
|
New categories assigned: alca @yuanchao,@francescobrivio,@malbouis,@tvami you have been requested to review this Pull request/Issue and eventually sign? Thanks |
A new Pull Request was created by @emanueleusai (Emanuele Usai) for master. It involves the following packages:
@malbouis, @yuanchao, @pmandrik, @emanueleusai, @ahmad3213, @tvami, @cmsbuild, @jfernan2, @francescobrivio, @pbo0, @rvenditti can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@mmusich Interesting. Somehow I forgot about @francescobrivio 's previous attempt. Anyway the deadline for the transition is now imminent so I think it's time to discuss this again. I implemented it in a slightly different way wrt Francesco, so let's see the result of the tests. Concerning the use of DQMOneEDAnalyzer, I largely agree with the discussion in the previous PR. Perhaps one can create a new DQMOne"LumiAndRun"EDAnalyzer that templates both edm:: one ::WatchLuminosityBlocks and edm:: one ::WatchRuns. But then one needs to rewrite AlcaBeamMonitorClient & others to access DQMStore through the DQMOne*EDAnalyzer interface rather than accessing it directly. I think just changing the class type isn't going to work. |
please test |
// BeginRun | ||
void beginRun(const edm::Run& r, const edm::EventSetup& c) override; | ||
// void beginRun(const edm::Run& r, const edm::EventSetup& c) override; |
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.
Should these be removed for good? (also the endRun
)
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.
yup I forgot to remove them after testing
please abort test |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37071/28541
|
Pull request #37071 was updated. @malbouis, @yuanchao, @pmandrik, @emanueleusai, @ahmad3213, @tvami, @cmsbuild, @jfernan2, @francescobrivio, @pbo0, @rvenditti can you please check and sign again. |
please test |
Let me rephrase. What's the preferred strategy from the DQM group? Clearly the plain old
Right, I admit I didn't follow much further Francesco's PR, but clearly just changing the method signatures is not gonna cut it, the |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-c66ac4/22686/summary.html The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: Comparison SummarySummary:
|
there's plenty of failures, presumably coming from the inclusion of the commits of #37034 in this PR. |
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 agree with @emanueleusai that a new DQMStore class could be used, but that would require a larger work to update all the plugins, maybe it can be posponed to later given that technically the one:EDAnalyzer
class is technically ok for the moment.
As @mmusich said @cms-sw/dqm-l2 maybe you can comment on what is the preferred solution from DQM point of view?
@@ -70,6 +70,8 @@ void AlcaBeamMonitorClient::beginRun(const edm::Run& r, const EventSetup& contex | |||
void AlcaBeamMonitorClient::analyze(const Event& iEvent, const EventSetup& iSetup) {} | |||
|
|||
//---------------------------------------------------------------------------------------------------------------------- | |||
void AlcaBeamMonitorClient::beginLuminosityBlock(const LuminosityBlock& iLumi, const EventSetup& iSetup) {} |
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.
Not related to this line, but shouldn't the ~AlcaBeamMonitorClient() {}
be changed to ~AlcaBeamMonitorClient() = default;
?
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 same comment can be applied to
- BeamConditionsMonitor.cc
- PixelVTXMonitor.cc
- Vx3DHLTAnalyzer.cc
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.
good point, I'll fix that too
@mmusich @francescobrivio We discussed this internally with the other @cms-sw/dqm-l2 . Our preferred position would be to first move from EDAnalyzer to one::EDAnalyzer or similar (e.g. DQMEDAnalyzer to DQMOneEDAnalyzer) in order to comply with the deprecation of EDAnalyzer. Then later on, in a separate set of PRs, address the issue of the DQM modules still not using DQM*EDAnalyzer and make sure DQMStore is not accessed directly, but only through the iBooker/iGetter methods. |
@cmsbuild, please test
|
From |
@makortel thank you for giving the core point of view on this. I can make an attempt at rewriting the module(s) to use DQM*EDAnalyzer but it'd be safer if BeamMonitor experts (AlCa developers I assume) can look into it if we go this way. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-c66ac4/22786/summary.html Comparison SummarySummary:
|
I am the only developer at the moment and I would need some time to (digest and) test the correct way to update these plugins (maybe following Javi's suggestion from #35501 (comment) since my last attempt with DQM*EDAnalyzer wasn't successful).
|
I guess I can help with that.
IMHO this solution is equivalent to sweeping the dust under the rug. The deprecation warning is gone, but then there's no guarantee it won't fail in production. |
Thanks!
The goal to migrate (at minimum) all legacy EDModules being used in production is by 13_0_0 (at which point we'll change the current warning message of such modules to an exception). |
PR description:
replacing EDAnalyzer with the appropriate edm::one version for various plugins in the DQM/BeamMonitor package.
No changes to ME expected.
PR validation:
DQM/BeamMonitor now compiles on CMSSW_12_3_CMSDEPRECATED_X_2022-02-21-2300 without warnings
if this PR is a backport please specify the original PR and why you need to backport that PR:
Not a backport