Bug fix in EMTF GEM and RPC unpacker blocks

[eyigitba]

PR description:

This PR fixes a bug that was mentioned in #39456

The bug was introduced in #39388

It was a stupid mistake on my part that somehow went in. The index for the for loop does not match the if/else statements, hence causing an empty GEM/RPC TP to be created which then causes the crash when we try to create detID.

This should be backported to 12_4_X and 12_5_X to fix the same ug in those releases.

PR validation:

Tested with running the unpacker on the data files mentioned in #39456. Unpacker runs and assigns the correct values to GEM/RPC TPs.

File used: /eos/cms/store/t0streamer/Data/Express/000/359/045/run359045_ls0144_streamExpress_StorageManager.dat

[eyigitba]

type bugfix

[eyigitba]

urgent

[tvami]

@cmsbuild , please test

• not like anything would test this (otherwise we would have noticed it in IB tests)

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-39460/32183

• This PR adds an extra 20KB to repository

[cmsbuild]

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

It involves the following packages:

• EventFilter/L1TRawToDigi (l1)

@epalencia, @rekovic, @cecilecaillol can you please review it and eventually sign? Thanks.
@dinyar, @missirol, @thomreis, @Martin-Grunewald 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

[cecilecaillol]

+l1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs after it passes the integration tests. 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]

+1

• The fix is quite logical, and as we realized there is no way to actually test it with the IB tests.
• @francescobrivio is currently testing it on a previously failing offline job, see GEM Det ID error in Online and Offline DQM #39456 (comment)
• Let therefore merge this in the master in order to have it included in the 2300 IB: if there are no issues, tomorrow we can also merge the backports

[perrotta]

merge

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7b33a4/27690/summary.html
COMMIT: 9cca0b1
CMSSW: CMSSW_12_6_X_2022-09-20-1100/el8_amd64_gcc10
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/39460/27690/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: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 51
• DQMHistoTests: Total histograms compared: 3621956
• DQMHistoTests: Total failures: 2
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3621932
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 50 files compared)
• Checked 212 log files, 49 edm output root files, 51 DQM output files
• TriggerResults: no differences found

[davidlange6]

On Sep 20, 2022, at 10:43 PM, Andrea Perrotta ***@***.***> wrote: +1 • The fix is quite logical, and as we realized there is no way to actually test it with the IB tests.

Why is there "no way"? (There is now clearly as express (at least) crashes) - but even in that case one can ask the requestor how was the code checked/validated.. I guess it wasn't in this case.

[eyigitba]

@davidlange6 , I verified the fix by testing it using the offline recipe as described in #39456.

Previously this error was missed in tests because I tested it using a run where GEM was offline (I wasn't aware). Since the firmware version change is quite recent, probably there were no IB tests using data collected with this firmware version. So the error did not appear in those tests.

[davidlange6]

On Sep 21, 2022, at 9:21 AM, eyigitba ***@***.***> wrote: @davidlange6 , I verified the fix by testing it using the offline recipe as described in #39456. Previously this error was missed in tests because I tested it using a run where GEM was offline (I wasn't aware). Since the firmware version change is quite recent, probably there were no IB tests using data collected with this firmware version. So the error did not appear in those tests.

But nor did that test show that your code actually worked - thats part of my point:) [the integration procedure needs to include positive checks not just lack of negative ones..imho]

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[perrotta]

Why is there "no way"? (There is now clearly as express (at least) crashes) - but even in that case one can ask the requestor how was the code checked/validated.. I guess it wasn't in this case.

Hi David. Let me rephrase in hopefully some better English.
"The PR tests were not able to spot this problem in origin, and therefore I did not wait for them being concluded for mergin this PR, but I rather relied on the results of the dedicated tests able to reproduce the ones that were failing without this PR, see #39456 (comment) and #39456 (comment)"

That said, yes I fully agree that the PR and IB tests should include Run3 data samples from runs that also include GEM, as it is not the case for the current ones. I'd let @cms-sw/pdmv-l2 deal with it and find the appropriate input files for them.

[eyigitba]

@davidlange6 , right that's a good point. I only verified the RPC part in my test and I didn't check the GEM part. On top of that, apparently I made a mistake when cleaning the RPC part which ended up being broken as well. I agree that checking for positive outcome is required (which I, apparently, failed to do properly).