10_6_X backport of "HCAL: slimmed collections... for miniAOD" (PR #31375)

[abdoulline]

PR description:

Two tiny-size "simmedHcalRecHits" collections
(HBHERecHitsSorted_slimmedHcalRecHits and HFRecHitsSorted_slimmedHcalRecHits) added to minAOD.

They contain solely RecHits with non-0 (noise) flags set. This is "slimmed" version (without HcalRecHits "interesting" for Egamma) of "reducedHcalRecHits" collections included in AOD.

PR validation:

runTheMatrix.py -l 136.88811 OK

if this PR is a backport please specify the original PR:

Yes, backport of #31375

[cmsbuild]

A new Pull Request was created by @abdoulline (Salavat Abdullin) for CMSSW_10_6_X.

It involves the following packages:

PhysicsTools/PatAlgos
RecoLocalCalo/HcalRecProducers

@perrotta, @jpata, @cmsbuild, @santocch, @slava77 can you please review it and eventually sign? Thanks.
@rappoccio, @gouskos, @hatakeyamak, @emilbols, @peruzzim, @seemasharmafnal, @mmarionncern, @apsallid, @ahinzmann, @smoortga, @jdolen, @ferencek, @jdamgov, @nhanvtran, @gkasieczka, @schoef, @andrzejnovak, @clelange, @riga, @JyothsnaKomaragiri, @gpetruc, @mariadalfonso this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

• CMSSW_10_6_X_2020-09-18-1100/slc7_amd64_gcc700: https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/9433/console Started: 2020/09/18 18:55

[cmsbuild]

+1
Tested at: aba08fc
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7effe4/9433/summary.html
CMSSW: CMSSW_10_6_X_2020-09-18-1100
SCRAM_ARCH: slc7_amd64_gcc700

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7effe4/9433/summary.html

Comparison Summary:

• No significant changes to the logs found
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 2 differences found in the comparisons
• DQMHistoTests: Total files compared: 34
• DQMHistoTests: Total histograms compared: 3214633
• DQMHistoTests: Total failures: 21
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3214278
• DQMHistoTests: Total skipped: 334
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
• Checked 140 log files, 14 edm output root files, 34 DQM output files

[jpata]

Coming to this now. The backport seems fine, exactly the same as the original PR. I guess the only question to decide is if it's fine for the no-change policy, as at least DQM can detect (tiny) changes:

I understand this arises if all rechits are read without checking the origin module. Should an era modifier be considered for this PR in 10_6?

[abdoulline]

But this issues has been discussed in "primary" PR #31375 :
this is a problem of rather obsolete particular Validation module
"Validation/GlobalRecHits/HCals : iterates over all the HCAL RecHits collections with getByType, so adding new ones (this case) may change the number of entries".

In physics results there are no differences ("no change policy" - compliant case).

[jpata]

I have no strong feeling one way or the other, the PR is technically fine and exactly as the original, just making this point that DQM will detect differences. I'm not sure what is the level of strictness for the no change policy.

@slava77 what do you suggest?

[perrotta]

I have no strong feeling one way or the other, the PR is technically fine and exactly as the original, just making this point that DQM will detect differences. I'm not sure what is the level of strictness for the no change policy.

As Salavat said in #31375 (comment), the "no change" (or, better, "at most add only") policy is respected here. Simply that validation plot, iterating over all HCAL RecHits, also includes now the newly added ones. If we accept that they are added, we must also accept that they show up in that validation plot

[slava77]

I have no strong feeling one way or the other, the PR is technically fine and exactly as the original, just making this point that DQM will detect differences. I'm not sure what is the level of strictness for the no change policy.

@slava77 what do you suggest?

I propose(d) to have it as is, but given that the "no-change" requirement is not perfectly preserved, I'd say it's up to @qliphy @silviodonato to agree if this proposal is OK.

[qliphy]

I am fine with this PR as it is.

[silviodonato]

I agree with the current PR. We are just adding new collections, it does not matter if the validation code see this as a "change".

[jpata]

+reconstruction

• direct backport of HCAL: slimmed collections with non-0 noise flags RecHits for miniAOD #31375
• no reco changes, but DQM changes are expected and observed due to HCAL: slimmed collections with non-0 noise flags RecHits for miniAOD #31375 (comment), this is accepted

[silviodonato]

merge

[santocch]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_10_6_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_11_2_X is complete. This pull request will be automatically merged.