Fix valEmtfStage2Digis for unpacked GEM clusters in GEN-SIM-RAW

[dildick]

PR description:

In response to issue #32634. This would allow the dqmoffline to run on GEN-SIM-RAW in Run-3 scenarios with GEMs included. Previously, valEmtfStage2Digis crashed because it could not find simMuonGEMPadDigiClusters. That is expected. A solution is provided where the GEM trigger primitive producers are run on unpacked GEM digis in GEN-SIM-RAW. Those GEM TP producers have prefixes valMuon. valMuonGEMPadDigiClusters may be replaced with emtfStage2Digis once the EMTF unpacker has been updated for GEM TPs in data and the collection is available in the event.

PR validation:

Code compiles. Tried the recipe in the first message of #32634.

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

N/A

Before submitting your pull requests, make sure you followed this checklist:

• verify that the PR is really intended for the chosen branch
• verify that changes follow CMS Naming, Coding, And Style Rules
• verify that the PR passes the basic test procedure suggested in the CMSSW PR instructions

[dildick]

@davidlange6 Can you provide an updated test recipe? I modified WF 11634.0, with

cmsDriver.py step3 --conditions auto:phase1_2021_realistic -n -10 --era Run3 --eventcontent AODSIM,MINIAODSIM,DQM --runUnscheduled -s RAW2DIGI,L1Reco,RECO,RECOSIM,EI,PAT,DQM:@rerecoCommon+@miniAODDQM --datatier AODSIM,MINIAODSIM,DQMIO --geometry DB:Extended --
nThreads 8 --filein file:step2.root --fileout recostep.root --suffix "-j JobReport5.xml " --customise Validation/Performance/TimeMemorySummary.customiseWithTimeMemorySummary

as the third step. It crashes with

Module: L1TMuonBarrelTrackProducer:valBmtfDigis (crashed)
Module: none
Module: none
Module: LXXXCorrectorProducer:ak4PFResidualCorrector
Module: L1TMuonBarrelKalmanStubProducer:valKBmtfStubs
Module: LXXXCorrectorProducer:ak4PFResidualCorrector
Module: L1TMuonCaloSumProducer:valGmtCaloSumDigis
Module: L1TRawToDigi:caloStage2Digis

A fatal system signal has occurred: segmentation violation
Segmentation fault

[dildick]

@jshlee @seungjin-yang

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33694/22606

• This PR adds an extra 20KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File Configuration/StandardSequences/python/RawToDigi_cff.py modified in PR(s): Redesign all GPU workflows to detect if a GPU is present, and fall back to CPU otherwise #33428

[cmsbuild]

A new Pull Request was created by @dildick (Sven Dildick) for master.

It involves the following packages:

Configuration/StandardSequences
EventFilter/GEMRawToDigi
L1Trigger/L1TMuonEndCap

@perrotta, @silviodonato, @fabiocos, @cmsbuild, @rekovic, @franzoni, @slava77, @jpata, @qliphy, @cecilecaillol, @davidlange6 can you please review it and eventually sign? Thanks.
@Martin-Grunewald, @fabiocos, @lecriste, @makortel, @felicepantaleo, @GiacomoSguazzoni, @watson-ij, @VinInn, @jshlee, @rovere, @thomreis, @dinyar, @ebrondol, @mtosi, @dgulhan, @slomeo this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[cecilecaillol]

please test

[dildick]

@jiafulow @eyigitba

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-aee89f/15000/summary.html
COMMIT: abdeb99
CMSSW: CMSSW_12_0_X_2021-05-10-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/33694/15000/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 5 differences found in the comparisons
• DQMHistoTests: Total files compared: 37
• DQMHistoTests: Total histograms compared: 2663174
• DQMHistoTests: Total failures: 12
• DQMHistoTests: Total nulls: 1
• DQMHistoTests: Total successes: 2663139
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.004 KiB( 36 files compared)
• DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
• Checked 155 log files, 37 edm output root files, 37 DQM output files
• TriggerResults: no differences found

[eyigitba]

Hi @dildick , this looks ok to me. I added a comment to your modification of simEmtfDigis.

EMTF unpacker is already updated to handle GEM info from EMTF DAQ path, but since we don't have it in firmware yet it shouldn't be doing anything for now. We can change this implementation once all the packers/unpackers are ready.

[cecilecaillol]

+l1

[dildick]

@slava77 Looking at it closer, I think we actually only need to change the input to valEmtfStage2Digis

[dildick]

Because the L1 DQM configuration file already defines

# GEM TPG
from L1Trigger.L1TGEM.simGEMDigis_cff import *
valMuonGEMPadDigis = simMuonGEMPadDigis.clone(InputCollection = "muonGEMDigis")
valMuonGEMPadDigiClusters = simMuonGEMPadDigiClusters.clone(InputCollection = "valMuonGEMPadDigis")

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-33694/22654

• This PR adds an extra 16KB to repository

[cmsbuild]

Pull request #33694 was updated. @andrius-k, @kmaeshima, @ErnestaP, @ahmad3213, @cmsbuild, @jfernan2, @rvenditti can you please check and sign again.

[jfernan2]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-aee89f/15068/summary.html
COMMIT: 3c7a63d
CMSSW: CMSSW_12_0_X_2021-05-12-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/33694/15068/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

The workflows 140.53 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons

Summary:

• No significant changes to the logs found
• Reco comparison results: 1264 differences found in the comparisons
• DQMHistoTests: Total files compared: 37
• DQMHistoTests: Total histograms compared: 2648242
• DQMHistoTests: Total failures: 3675
• DQMHistoTests: Total nulls: 19
• DQMHistoTests: Total successes: 2644526
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 45.703 KiB( 36 files compared)
• DQMHistoSizes: changed ( 140.53 ): 44.531 KiB Hcal/DigiRunHarvesting
• DQMHistoSizes: changed ( 140.53 ): 1.172 KiB RPC/DCSInfo
• Checked 155 log files, 37 edm output root files, 37 DQM output files
• TriggerResults: no differences found

[jfernan2]

@dildick it is not clear to me if this needs to be backported to 11_3_X or not in view of next MWGR

[dildick]

I don't think it needs to be backported.

@davidlange6 Can you provide a recipe to test it on GEN-SIM-RAW and whether or not this needs to be backported?

[dildick]

Failures from messagelogger, pixel and DD4Hep

@jfernan2 Do you have other questions or comments? Switching from simMuonGEMPadDigiClusters (simulated) to valMuonGEMPadDigiClusters (re-emulated on unpacked digis) seems to be fine. I was not expecting any problems.

[silviodonato]

yes, the differences in 140.53 are explained above

The workflows 140.53 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons

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

[silviodonato]

+1
@dildick although we will not run any rereco in 11_3_0, it might be good to have a backport if the bug is reproducible in 11_3_X