DQM: Allow per-lumi MEs in DQMOneEDAnalyzer

[schneiml]

PR description:

After the discussion started by @Dr15Jones in #29314 , I remembered that we still had the option to do the lumi-switching in the DQMStore on a per-event basis. This allows modules like METAnalyzer to book per-lumi histograms but remain DQMOneEDAnalyzer and yet not block concurrent lumis.

The cost is higher overhead. The enterLumi/leaveLumi calls should be fast in the common case (take a lock, do a map lookup, do nothing), but with many lumi MEs (for example when per-lumi saving by default like in the UL ReReco) all the pointer bending could cause some overhead. However, even that might still be negligible, or could be optimized a bit more if it is a problem.

PR validation:

I tested a workflow with METAnalyzer and it seems to come out well. The PR tests should catch eventual differences.

I also updated the unit tests to excercise this feature and it seems fine. However, I don't observe any concurrent lumis in the unit tests, even though they are enabled and there should not be any blocking modules. It would be nice to see some test case where events actually alternate between lumis.

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29321/14398

• This PR adds an extra 28KB to repository

[cmsbuild]

A new Pull Request was created by @schneiml (Marcel Schneider) for master.

It involves the following packages:

DQMOffline/JetMET
DQMServices/Core
DQMServices/Demo

@andrius-k, @kmaeshima, @schneiml, @cmsbuild, @jfernan2, @fioriNTU can you please review it and eventually sign? Thanks.
@mmarionncern, @barvic, @ahinzmann, @rappoccio, @jdamgov, @jdolen, @nhanvtran, @gkasieczka, @clelange, @schoef, @mariadalfonso, @seemasharmafnal, @rociovilar 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

[schneiml]

please test

There should not be any differences, and that should actually sort of validate the change.

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/5412/console Started: 2020/03/27 16:17

[cmsbuild]

-1

Tested at: 3c328d9

CMSSW: CMSSW_11_1_X_2020-03-27-1100
SCRAM_ARCH: slc7_amd64_gcc820
You can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-d2f47f/5412/summary.html

I found follow errors while testing this PR

Failed tests: ClangBuild

• Clang:

I found compilation warning while trying to compile with clang. Command used:

USER_CUDA_FLAGS='--expt-relaxed-constexpr' USER_CXXFLAGS='-Wno-register -fsyntax-only' scram build -k -j 32 COMPILER='llvm compile'

See details on the summary page.

[cmsbuild]

Comparison not run due to Build errors/Fireworks only changes/No short matrix requested (RelVals and Igprof tests were also skipped)

[schneiml]

Unless anybody objects (@Dr15Jones , @makortel ?) I think this is a viable solution. Paying special attention to the DQMOneEDAnalyzers in RelVals is of course mandated, esp. if concurrent lumis are actually used (I don't think the DQM unit tests that enable concurrent lumis actually managed to produce some events where the one modules went back-and forth between lumis).

Otherwise, I think we can go ahead here.

[schneiml]

please test

Nothing changes, but the pervious comparison is gone and things may have changed in master.

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/5646/console Started: 2020/04/10 10:59

[cmsbuild]

+1
Tested at: 466e9d7
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-d2f47f/5646/summary.html
CMSSW: CMSSW_11_1_X_2020-04-09-2300
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-d2f47f/5646/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: 2694590
• DQMHistoTests: Total failures: 50
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2694221
• DQMHistoTests: Total skipped: 319
• 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

[schneiml]

The changes in 1330 are unexpected. They were also present in the previous tests and are not in #29438 (which is clean otherwise). So, this needs to be investigated.

[schneiml]

It turns out the changes here are a well known problem.

So, this looks all fine to me.

[schneiml]

+1

[cmsbuild]

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

[silviodonato]

+1