Consume records for mustache SC only if the mustache algo is used - 112x backport

[thomreis]

PR description:

Use the records for EcalMustacheSCParameters and EcalSCDynamicDPhiParameters only if the SC algorithm is configured to run the mustache and/or the dynamic dPhi. This should avoid exceptions if the records are not in the GT. No changes to the outputs are expected.
The ESProducers for the records are still kept in the default configuration since not all necessary GTs contain the records already.
Backport to 112x since the new records are also consumed in the 11_2_X release.

PR validation:

Passes limited matrix tests.

if this PR is a backport please specify the original PR and why you need to backport that PR:

Backport of #32997

[cmsbuild]

A new Pull Request was created by @thomreis (Thomas Reis) for CMSSW_11_2_X.

It involves the following packages:

RecoEcal/EgammaClusterAlgos
RecoEcal/EgammaClusterProducers

@perrotta, @jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@Sam-Harper, @lecriste, @rchatter, @jainshilpi, @rovere, @lgray, @sobhatta, @thomreis, @afiqaize, @simonepigazzini, @argiro, @varuns23, @ram1123 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

• Backported from Consume records for mustache SC only if the mustache algo is used #32997

[thomreis]

backport of #32997

[slava77]

@thomreis
is the backport really necessary?
What are the anticipated conditions for seeing the problem? Is it something we expect in MWGR?

[thomreis]

No I do not expect this to be needed in an upcoming MWGR. It would rather be for MC productions where the mustache algorithm does not run and we do not have the parameters in the GT. I do not know if this situation will happen though.

[slava77]

It would rather be for MC productions where the mustache algorithm does not run and we do not have the parameters in the GT. I do not know if this situation will happen though.

Thank you for clarifying.

I'm not aware of existing problem in production.
For future production requests I would expect that a GT is prepared appropriately/consistently with the appropriate payloads.
OTOH, this PR is rather technical and small.

It sounds like this is a "nice to have" (not a required feature).
So, I reco will check and sign, but will not push for a new release built with just this.

[slava77]

@cmsbuild please test

[thomreis]

Yes, this is not something that needs to be added urgently. But it completes the changes in PR #32066 could save us from some potential head scratching in the future.
Without this PR a future legacy production would eventually require mustache payloads to be added to the GT that are never used just to avoid a crash.

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-833b34/13336/summary.html
COMMIT: d764fed
CMSSW: CMSSW_11_2_X_2021-03-08-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week1/cms-sw/cmssw/33100/13336/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: 36
• DQMHistoTests: Total histograms compared: 2527501
• DQMHistoTests: Total failures: 1
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2527478
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 35 files compared)
• Checked 151 log files, 37 edm output root files, 36 DQM output files

[slava77]

+1

for #33100 d764fed

• the backport is correct and is OK for 112X given that this is technical in normal setup and would resolve crashes for older GTs. As discussed above, it would be nice to have, but does not by itself requires a release build
• jenkins tests pass and comparisons with the baseline show no differences as expected

[cmsbuild]

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

[qliphy]

+1