Update to remove per bx roc data - 14_0_X

[perrotta]

The modules affected:
Calibration/LumiAlCaRecoProducers
DataFormats/Luminosity

Minor change to the structure of per roc data. Effectively removes per bx granularity (hence reducing the array size by 3563), to resolve the memory usage issue raised in #45306

backport of #45348

[cmsbuild]

A new Pull Request was created by @perrotta for CMSSW_14_0_X.

It involves the following packages:

• DataFormats/Luminosity (reconstruction)

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

cms-bot commands are listed here

• Backported from update to remove per bx roc data #45348

[cmsbuild]

cms-bot internal usage

[perrotta]

please test

[perrotta]

backport of #45348

[perrotta]

type bug-fix

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-5407a1/40202/summary.html
COMMIT: 15b0549
CMSSW: CMSSW_14_0_X_2024-07-03-1100/el8_amd64_gcc12
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/45369/40202/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially added 74 lines to the logs
• Reco comparison results: 146 differences found in the comparisons
• DQMHistoTests: Total files compared: 48
• DQMHistoTests: Total histograms compared: 3342828
• DQMHistoTests: Total failures: 2739
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3340069
• DQMHistoTests: Total skipped: 20
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 47 files compared)
• Checked 202 log files, 165 edm output root files, 48 DQM output files
• TriggerResults: no differences found

[mandrenguyen]

type lumi

[mandrenguyen]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_14_0_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_14_1_X is complete. This pull request will now be reviewed by the release team before it's merged. @sextonkennedy, @antoniovilela, @rappoccio (and backports should be raised in the release meeting by the corresponding L2)

[perrotta]

urgent
(to be included in next 14_0_X)

[antoniovilela]

+1

[perrotta]

type changes-dataformats

[mmusich]

type changes-dataformats

IIUC cms-sw/cms-bot#2245, this PR doesn't quality for this label as there is a change in the content but not in the class layout (@makortel please correct me if I a mistaken).

[perrotta]

type changes-dataformats

IIUC cms-sw/cms-bot#2245, this PR doesn't quality for this label as there is a change in the content but not in the class layout (@makortel please correct me if I a mistaken).

I wanted to indicate that the size of the output data as ruled by the DataFormat has changed, which is what was being discussed today at the TSG meeting, Indeed the layout of the class wasn't changed, and therefore the label can be questionable: nonetheless, since this PR is already included in a full cmssw release since a while already, it will not be used to decide whether to make a patch or a full release. But I can remove it if people think it is not due.

[makortel]

type changes-dataformats

IIUC cms-sw/cms-bot#2245, this PR doesn't quality for this label as there is a change in the content but not in the class layout (@makortel please correct me if I a mistaken).

I wanted to indicate that the size of the output data as ruled by the DataFormat has changed, which is what was being discussed today at the TSG meeting, Indeed the layout of the class wasn't changed, and therefore the label can be questionable: nonetheless, since this PR is already included in a full cmssw release since a while already, it will not be used to decide whether to make a patch or a full release. But I can remove it if people think it is not due.

I think the changes-dataformats should include also changes that do not change the physical class layout, but change the interpretation of the data in an incompatible way. In other words, if data stored with/without this PR would fail to be read correctly without/with this PR, I'd say the changes-dataformats label would be justified.

We should probably try to formalize the intention (policy) of changes-dataformats and write it down e.g. in https://twiki.cern.ch/twiki/bin/viewauth/CMS/ReleaseSchedule .