add PileupSummaryInfos_addPileupInfo to SiPixelCalSingleMuonTight output data-tier

[mmusich]

PR description:

Title says it all. Needed for pixel dynamic inefficiency studies, as reported here, see for long version also here.

PR validation:

Run the command:

cmsDriver.py -s ALCA:SiPixelCalSingleMuonTight --conditions 124X_mcRun3_2022_realistic_postEE_forPixelIneff_v5 --eventcontent=ALCARECO --datatier ALCARECO -n 10000 --no_exec --era Run3 --python_filename=SingleMuonTightCombinedMC.py --nThreads=8 --filein=/store/relval/CMSSW_12_4_12/RelValZMM_PU_13p6/GEN-SIM-RECO/PU_124X_mcRun3_2022_realistic_postEE_forPixelIneff_v5_PDMVRELVALS188_HS_2023PU-v1/00000/05930f72-62dc-45fd-814b-2652a4ddd08d.root

with this branch and without and found the following changes:

< File SiPixelCalSingleMuonTight_new.root Events 1103
---
> File SiPixelCalSingleMuonTight.root Events 1103
4,22c4,21
< PileupSummaryInfos_addPileupInfo__HLT. 24663 8817.56
< recoMuons_muons__RECO. 18709.7 6319.87
< recoVertexs_offlinePrimaryVertices__RECO. 45693.1 5982.61
< recoVertexsedmAssociation_offlinePrimaryVertices__RECO. 5417.33 1329.82
< EventProductProvenance 4409.7 651.125
< intedmValueMap_offlinePrimaryVertices__RECO. 5398.31 371.293
< recoTrackExtras_ALCARECOSiPixelCalSingleMuonTight__ALCA. 473.744 348.975
< recoTracks_ALCARECOSiPixelCalSingleMuonTight__ALCA. 589.343 261.811
< SiStripClusteredmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 682.138 229.76
< floatedmValueMap_offlinePrimaryVertices__RECO. 247.966 190.427
< TrackingRecHitsOwned_ALCARECOSiPixelCalSingleMuonTight__ALCA. 1648.62 183.922
< SiPixelClusteredmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 346.11 166.796
< SiPixelClusteredmNewDetSetVector_closebyPixelClusters__ALCA. 344.534 164.618
< edmTriggerResults_TriggerResults__HLT. 1527.38 63.7217
< Phase2TrackerCluster1DedmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 78.7643 35.2466
< EventAuxiliary 115.829 14.3083
< floatsedmValueMap_trackDistances__ALCA. 65.3626 13.2248
< EventSelections 92.1442 6.30372
< BranchListIndexes 25.1686 3.18223
---
> recoMuons_muons__RECO. 18718 6361.84
> recoVertexs_offlinePrimaryVertices__RECO. 45703.9 6008.53
> recoVertexsedmAssociation_offlinePrimaryVertices__RECO. 5421.87 1336.26
> EventProductProvenance 4410.01 883.01
> intedmValueMap_offlinePrimaryVertices__RECO. 5402.4 377.336
> recoTrackExtras_ALCARECOSiPixelCalSingleMuonTight__ALCA. 465.82 339.411
> recoTracks_ALCARECOSiPixelCalSingleMuonTight__ALCA. 581.367 252.24
> SiStripClusteredmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 678.673 223.561
> floatedmValueMap_offlinePrimaryVertices__RECO. 247.745 190.081
> TrackingRecHitsOwned_ALCARECOSiPixelCalSingleMuonTight__ALCA. 1649.56 186.464
> SiPixelClusteredmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 342.141 161.065
> SiPixelClusteredmNewDetSetVector_closebyPixelClusters__ALCA. 340.872 159.252
> edmTriggerResults_TriggerResults__HLT. 1528.05 66.9565
> Phase2TrackerCluster1DedmNewDetSetVector_ALCARECOSiPixelCalSingleMuonTight__ALCA. 75.6074 31.505
> EventAuxiliary 115.728 14.0508
> floatsedmValueMap_trackDistances__ALCA. 65.0462 12.796
> EventSelections 92.4488 6.83862
> BranchListIndexes 25.0834 3.07978

The additional collection (as measured on around 1k events) adds about 8kB/event, so the overall on-file size is increased by 40%

• this is undoubtedly sizeable, but as per AlCa conveners advice (@tvami): "this ALCARECO has an order of magnitude less events than other ALCARECOs, so even the 40% increase will make the size reasonable ".
• Moreover it should only be there for MC (which I think we unfrequently run, except in relvals)

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:

might be useful to backport to 13.0.X (though it will trigger a change of processing version)

cc:
@ferencek @mroguljic FYI

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-41411/35279

• This PR adds an extra 12KB to repository

[cmsbuild]

A new Pull Request was created by @mmusich (Marco Musich) for master.

It involves the following packages:

• Calibration/TkAlCaRecoProducers (alca)

@cmsbuild, @tvami, @saumyaphor4252, @francescobrivio can you please review it and eventually sign? Thanks.
@mmusich, @threus, @tocheng 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

[mmusich]

@cmsbuild, please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-bc50dc/32159/summary.html
COMMIT: f31f7f5
CMSSW: CMSSW_13_1_X_2023-04-26-1100/el8_amd64_gcc11
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/41411/32159/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially added 7 lines to the logs
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 48
• DQMHistoTests: Total histograms compared: 3460685
• DQMHistoTests: Total failures: 0
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3460663
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 47 files compared)
• Checked 207 log files, 159 edm output root files, 48 DQM output files
• TriggerResults: no differences found

[tvami]

+alca

• relevant wf-s run correctly
• size increase happens in limited situations so it is acceptable

[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]

+1

[tvami]

I'll bring up the discussion about the backport at ORP today, but I think it would make sense to have it backported.

[mmusich]

I'll bring up the discussion about the backport at ORP today, but I think it would make sense to have it backported.

here it is: #41484