DQMCertCommon is not used, customize DQMCertTrackerPixel instead

[mmusich]

PR description:

Minimal fix for issue described at https://hypernews.cern.ch/HyperNews/CMS/get/tier0-Ops/2161.html.
DQMCertCommon is de facto not used (https://github.com/cms-sw/cmssw/search?q=DQMCertCommon&unscoped_q=DQMCertCommon) and can be removed.

PR validation:

I tested with runTheMatrix.py -l limited -i all -t 4 -j 8 --ibeos.

if this PR is a backport please specify the original PR and why you need to backport that PR:

Not a backport.

[cmsbuild]

The code-checks are being triggered in jenkins.

[mmusich]

I tried to test the Tier-0 setup with:

python $CMSSW_BASE/src/Configuration/DataProcessing/test/RunDQMHarvesting.py --scenario=ppEra_Run3 --global-tag=110X_dataRun3_Prompt_v3 --lfn=file:/eos/cms/store/data/Commissioning2020/MinimumBias/DQMIO/PromptReco-v1/000/335/443/00000/8E8B0136-607B-FD45-8AB6-6AAC0BC37497.root --run=335443 --dataset=/A/B/C --dqmi

but apparently the right harvesting sequences are not picked up. I am not sure how it is possible to configure a specific harvesting sequence using Configuration/DataProcessing, suggestions are welcome.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29021/13872

• This PR adds an extra 12KB to repository

[cmsbuild]

A new Pull Request was created by @mmusich (Marco Musich) for master.

It involves the following packages:

DQMOffline/Configuration

@andrius-k, @kmaeshima, @schneiml, @cmsbuild, @jfernan2, @fioriNTU can you please review it and eventually sign? Thanks.
@threus, @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

[jfernan2]

please test
thanks @mmusich

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/4827/console Started: 2020/02/22 08:58

[cmsbuild]

+1
Tested at: 174155a
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-c0f722/4827/summary.html
CMSSW: CMSSW_11_1_X_2020-02-21-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-c0f722/4827/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: 2694086
• DQMHistoTests: Total failures: 1
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2693766
• 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

[jfernan2]

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

[silviodonato]

I tried to test the Tier-0 setup with:

python $CMSSW_BASE/src/Configuration/DataProcessing/test/RunDQMHarvesting.py --scenario=ppEra_Run3 --global-tag=110X_dataRun3_Prompt_v3 --lfn=file:/eos/cms/store/data/Commissioning2020/MinimumBias/DQMIO/PromptReco-v1/000/335/443/00000/8E8B0136-607B-FD45-8AB6-6AAC0BC37497.root --run=335443 --dataset=/A/B/C --dqmi

but apparently the right harvesting sequences are not picked up. I am not sure how it is possible to configure a specific harvesting sequence using Configuration/DataProcessing, suggestions are welcome.

Any idea @andrius-k @jfernan2 @kmaeshima @fioriNTU @schneiml ?

[schneiml]

@mmusich @silviodonato you might have better luck with these tools: https://twiki.cern.ch/twiki/bin/view/CMSPublic/DqmWrappers
https://github.com/andresfelquintero/wrappers

[mmusich]

@silviodonato what's holding this PR?
The release is currently broken without it.

@schneiml,
thanks, but it looks to me it's using the same tool under the hood:

https://github.com/andresfelquintero/wrappers/blob/aaa32fdb5cd30dbfb26adca772b6d1610f0bcecc/harvestWrapper.sh#L32

[schneiml]

@mmusich This is what T0 provided to us as "the truth". If it behaves differently from T0 itself, I think that should be considered a bug on their side.

[mmusich]

@schneiml, I am not saying there is any bug, what I am still missing is how to configure any of these tool to accept an harvesting sequence different from the default (i.e dqmHarvesting).
Certainly there must be a way given that the actual Tier-0 workflow does it. I am just missing how do it in a test enviroment.

[schneiml]

@mmusich The database queried by this wrapper indeed knows the sequence [1], but the script seems to not use it.

Some experiments I just did show that the old sipixel* modules are only loaded on @common, not on @commonSiStripZeroBias. Having both of them in the MinBias Tier0 config is clearly a bug [2] there -- introduced with era 2018C [3] and probably not spotted since then because we never processed MinBias data since then. I assume @common should be removed there.

But clearly, using @common should work too, and it remains a mystery how this survived the replay test.

[1] https://cmsweb.cern.ch/t0wmadatasvc/prod/reco_config?run=335443&primary_dataset=MinimumBias
[2] The only reason it is @commonSiStripZeroBias instead of @common+@SiStripZeroBias is that it is not possible to run both at the same time.
[3] https://github.com/dmwm/T0/pull/4448/files#diff-49ee9258c3a81a3f0c3f7d62494aeb5fR926

[silviodonato]

+1

[mmusich]

@schneiml

The database queried by this wrapper indeed knows the sequence [1], but the script seems to not use it.

maybe @andresfelquintero can shed some light?

Having both of them in the MinBias Tier0 config is clearly a bug [2] there -- introduced with era 2018C [3] and probably not spotted since then because we never processed MinBias data since then. I assume @common should be removed there.

This goes along the lines of the message: https://hypernews.cern.ch/HyperNews/CMS/get/tier0-Ops/2161/1/1/1.html (which by the way seems it has already been implemented by Tier-0 judging from https://cmsweb.cern.ch/t0wmadatasvc/prod/reco_config).

[andresfelquintero]

So I am currently checking the bug as suggested by @schneiml . The problem with my wrapper is that it uses DQMHarvesting.py and I do not have a way of defining the correct harvesting sequence right now. As @mmusich says, I changed the dqm_seq on tier0 headnode when the DQM team gave us authorization. From now on it won't include @common or any other sequence rather than the desired one. We are looking into the problem now, and I think it is related to how we take the dqm sequences for replay, as it may be different from how we do it on production regarding the dqm sequence picking for processing.