Fixing the maximum number of OMTF final candidates

[kbunkow]

PR description:

Fix in the:
L1Trigger/L1TMuonOverlapPhase1/src/Omtf/GhostBusterPreferRefDt.cc L1Trigger/L1TMuonOverlapPhase1/src/Omtf/GhostBuster.cc The maximum number of the OMTF final candidates is limited to 3 - as in the hardware. Without his fix, the maximum number of final candidates could be 4. This addresses #39453

PR validation:

The PR was checked looking at the Run: 356531 Event: 9968011 - with the fix the OMTF emulator produces 3 candidates (and not 4 as without the fix), the candidates are the same as recorded from the hardware. In other events there are no changes.

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:

This PR is not a backport.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39624/32418

• This PR adds an extra 16KB to repository

[cmsbuild]

A new Pull Request was created by @kbunkow for master.

It involves the following packages:

• L1Trigger/L1TMuonOverlapPhase1 (l1)

@epalencia, @cmsbuild, @cecilecaillol, @rekovic can you please review it and eventually sign? Thanks.
@JanFSchulte, @eyigitba, @Martin-Grunewald, @missirol, @thomreis, @dinyar this is something you requested to watch as well.
@perrotta, @dpiparo, @rappoccio you are the release manager for this.

cms-bot commands are listed here

[epalencia]

Please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7699c3/28017/summary.html
COMMIT: ee12a62
CMSSW: CMSSW_12_6_X_2022-10-04-2300/el8_amd64_gcc10
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/39624/28017/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

There are some workflows for which there are errors in the baseline:
11634.15 step 3
The results for the comparisons for these workflows could be incomplete
This means most likely that the IB is having errors in the relvals.The error does NOT come from this pull request

@slava77 comparisons for the following workflows were not done due to missing matrix map:

• /data/cmsbld/jenkins/workspace/compare-root-files-short-matrix/data/PR-7699c3/41834.0_TTbar_14TeV+2026D94+TTbar_14TeV_TuneCP5_GenSimHLBeamSpot14+DigiTrigger+RecoGlobal+HARVESTGlobal

Summary:

• No significant changes to the logs found
• Reco comparison results: 9 differences found in the comparisons
• DQMHistoTests: Total files compared: 49
• DQMHistoTests: Total histograms compared: 3391103
• DQMHistoTests: Total failures: 9
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3391072
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 48 files compared)
• Checked 204 log files, 49 edm output root files, 49 DQM output files
• TriggerResults: no differences found

[epalencia]

+l1

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

[perrotta]

The PR was checked looking at the Run: 356531 Event: 9968011 - with the fix the OMTF emulator produces 3 candidates (and not 4 as without the fix), the candidates are the same as recorded from the hardware. In other events there are no changes.

@kbunkow , just co check: you verified in Run: 356531 Event: 9968011 that when there are originally 4 candidates you end up with the same three selected, as in hardware. Is that true "by construction", i.e. the refHitCands are somehow sorted so that the last one in case they are 4 is the one that would be also discarded in hardware, or it was discarded the right one only by chance in that specific run/event instead?

[perrotta]

By the way, @kbunkow @cecilecaillol @epalencia : should this get backported to 12_5 and 12_4?

[kbunkow]

just co check: you verified in Run: 356531 Event: 9968011 that when there are originally 4 candidates you end up with the same three selected, as in hardware. Is that true "by construction", i.e. the refHitCands are somehow sorted so that the last one in case they are 4 is the one that would be also discarded in hardware, or it was discarded the right one only by chance in that specific run/event instead?

The refHitCands are sorted, see https://github.com/kbunkow/cmssw/blob/ee12a6268afcf96a60973f698fb806757c7249ab/L1Trigger/L1TMuonOverlapPhase1/src/Omtf/GhostBusterPreferRefDt.cc#L116 and https://github.com/kbunkow/cmssw/blob/ee12a6268afcf96a60973f698fb806757c7249ab/L1Trigger/L1TMuonOverlapPhase1/src/Omtf/GhostBuster.cc#L17
So it should be assured that the firmware and emulator drop the same candidates in case there are 4 of them per OMTF processor
(btw. I think in the PR comment I was not clear, that the issue applies to the number of candidates per OMTF processors, not the total number of OMTF candidates in the event).

should this get backported to 12_5 and 12_4?
The impact of this fix on the OMTF and uGMT performance is negligible.
In the DQM this bug plays no role, since the uGMT emulator takes the input data from its own DAQ, where by construction only max 3 OMTF candidates per processor are present.
So this bugfix matters only when the RegionalMuonGmtPacker takes its input from the OMTF emulator (then it crashes if it gets 4 OMTF candidates) - I am not sure if 12_5 and 12_4 will be used for something important in such a mode - if yes, then this PR should be backported.

Karol

[perrotta]

+1

[kpedro88]

Is it possible to backport this PR to 12_4_X? I am encountering this error while producing MC with many muons in configs based on the Run3Summer22 campaign, which uses that release cycle.