Fixes mismatches between emulator and fw on CDC dimuon seed

[nabrandman]

PR description:

Corrects mismatches between emulator and firmware from L1_CDC_SingleMu_3_er1p2_TOP120_DPHI2p618_3p142
This particular algorithm requires muon information from the current bunch crossing and the previous bunch crossing, this fix stores the previous bunch crossings in vectors so that the emulator can continue to access this muon data to check the conditions of this algorithm.

No changes are expected in the output.
This PR does not rely on any other PRs or externals.

PR validation:

Performed runTheMatrix with -l 11634.0, passed 5 out of 5 tests.
Test vector code was in agreement with firmware.
Changes were checked against "scram build code-format" to ensure they followed CMS Naming, Coding and Style Rules.

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]

cms-bot internal usage

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46026/41825

[cmsbuild]

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

It involves the following packages:

• L1Trigger/L1TGlobal (l1)

@aloeliger, @cmsbuild, @epalencia can you please review it and eventually sign? Thanks.
@Martin-Grunewald, @missirol, @mmusich this is something you requested to watch as well.
@antoniovilela, @mandrenguyen, @rappoccio, @sextonkennedy you are the release manager for this.

cms-bot commands are listed here

[mmusich]

what's the interplay of this with #44940 and CMSHLT-3216?

[nabrandman]

what's the interplay of this with #44940 and CMSHLT-3216?

If I understand the linked issues correctly then this PR shouldn't have any affect on them.

It looks to me like the problem described was that the object map didn't contain information about which BX an object came from, and so the HLTL1TSeed exclusively tried to add objects from BX=0, but sometimes when the object map was referring to an object from BX=-1 HLTL1TSeed would try to add a non-existent object, causing a crash.

All this PR changes is what muons the uGT emulator considers to be in BX=-1 & BX=-2 when evaluating if objects pass the conditions. So if HLTL1TSeed isn't adding objects from BX=-1 or BX=-2 anyway then this PR shouldn't affect it.

[mmusich]

@cmsbuild, please test

[cmsbuild]

+1

Size: This PR adds an extra 12KB to repository
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-25b296/41603/summary.html
COMMIT: c8aefec
CMSSW: CMSSW_14_2_X_2024-09-18-1100/el8_amd64_gcc12
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/46026/41603/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially added 1 lines to the logs
• Reco comparison results: 5 differences found in the comparisons
• DQMHistoTests: Total files compared: 44
• DQMHistoTests: Total histograms compared: 3331158
• DQMHistoTests: Total failures: 6
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3331132
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 43 files compared)
• Checked 193 log files, 163 edm output root files, 44 DQM output files
• TriggerResults: no differences found

[aloeliger]

+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. @rappoccio, @mandrenguyen, @antoniovilela, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2)

[mandrenguyen]

+1

[missirol]

@cms-sw/l1-l2

I think #47030 shows (see its description) a case where this PR seems to introduce a disagreement between firmware and emulated decisions of the CDC seed (as opposed to removing such discrepancies).

Is it possible to have more details on the validation done for this PR ?

Is there a recipe to reproduce (a) the CDC firmware/emulator discrepancies seen before this PR, and (b) the removal of said discrepancies thanks to this PR ?

[aloeliger]

@cms-sw/l1-l2

I think #47030 shows (see its description) a case where this PR seems to introduce a disagreement between firmware and emulated decisions of the CDC seed (as opposed to removing such discrepancies).

Is it possible to have more details on the validation done for this PR ?

Is there a recipe to reproduce (a) the CDC firmware/emulator discrepancies seen before this PR, and (b) the removal of said discrepancies thanks to this PR ?

@elfontan @nabrandman

[elfontan]

Hi @missirol @aloeliger all,
Sorry for the late reply, I was waiting for a Rucio rule to access an EphemeralHLTPhysics dataset (ready just now) and repeat the kind of validation that (I guess) @nabrandman performed with this PR some months ago.

@nabrandman focused on checking the agreement via test vectors with the GT firmware, and the recipe followed was probably something like in the following. I ask him to confirm if the results that he observed were similar (e.g. an increased number of cases in which the emulator fires, as observed in the firmware and if the behaviour of the firmware test vector code was by chance counting all triggers -in all BXs- as opposed to only triggers in BX 0).

Validation steps

General recipe to prepare test vectors from data (in CMSSW_14_2_0_pre2, where cms-sw/cmssw#46026 is integrated):

cmsrel CMSSW_14_2_0_pre2
cd CMSSW_14_2_0_pre2/src/
git cms-init
cmsenv
git cms-init
git cms-addpkg L1Trigger/L1TGlobal
cd L1Trigger/L1TGlobal/
mkdir -p data/Luminosity/startup
cd data/Luminosity/startup
wget https://raw.githubusercontent.com/cms-l1-dpg/L1MenuRun3/refs/heads/master/development/L1Menu_Collisions2024_v1_3_0/L1Menu_Collisions2024_v1_3_0.xml
cd -
cp test/testVectorCode_data.py .                     # FOR DATA
> Edit testVectorCode_data.py and 1) make sure xml file is "L1Menu_Collisions2024_v1_3_0.xml" 2) Use a proper data file
voms-proxy-init --rfc --voms cms -valid 192:00
cmsRun testVectorCode_data.py 

A good data file to run from EphemeralHLTPhysics2 (now accessible thanks to a Rucio rule by @mtosi)

"/store/data/Run2024I/EphemeralHLTPhysics2/RAW/v1/000/386/593/00000/184a7ffb-babe-47de-a3f8-9a4190b2b011.root", 

The same flow can be run in CMSSW_14_2_0_pre1, instead, where PR cms-sw/cmssw#46026 is not available. (We can compare results between the two releases to reproduce before/after fix, equivalent to adding the PR on top of CMSSW_14_2_0_pre1.

Results (for 1 orbit=3564 events):

CMSSW_14_2_0_pre2:
L1_CDC_SingleMu_3_er1p2_TOP120_DPHI2p618_3p142        19        19        19

CMSSW_14_2_0_pre1: 
L1_CDC_SingleMu_3_er1p2_TOP120_DPHI2p618_3p142         5         5         5