Fix CSC, RPC, and DT digi validation configurations for premixing

[makortel]

This issue tracks work to fix the inconsistency in CSC, RPC, and DT digi validation configuration files for premixing reported first here
https://hypernews.cern.ch/HyperNews/CMS/get/muon-performance/982.html

It turns out that the necessary signal+pileup SimDigi collections are not part of the FEVTDEBUGHLT event content. If we want to keep premixing stage2 workflows running, we have to

• 1. Add the necessary collections to FEVTDEBUGHLT event content
• 2. Wait for next RelVals to have a new pileup library with the fixed event content
• 3. Fix the validation configurations to use the proper input
• 4. Drop the signal-only SimDigi collections from FEVTDEBUGHLT event content

[cmsbuild]

A new Issue was created by @makortel Matti Kortelainen.

@davidlange6, @Dr15Jones, @smuzaffar, @fabiocos can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

@mdhildreth @kpedro88 @fabiocos

If we follow the route suggested in the description, we get these histograms fixed in 10_2_0_pre3 at the earliest.

An alternative would be to accept the failures of stage2-only workflows after point 3 is merged, and rely on the combined stage1+stage2 workflow provided by #22956 to keep the full premixing chain tested. Then we could skip 2 and combine 1+3 (possibly 4 as well) and get the histograms fixed in pre2.

What do you think? The changes for 1 and 3 themselves are straightforward (and I have them done in my development branch already).

[kpedro88]

From my perspective, it's fine not to wait for a new relval premixing library.

We could modify the validation code just to skip some actions if the input handles aren't valid (instead of issuing a not found exception) to avoid failing workflows.

[makortel]

We could modify the validation code just to skip some actions if the input handles aren't valid (instead of issuing a not found exception) to avoid failing workflows.

Good idea, that would work as a temporary workaround (even if in general I dislike such pattern if input is expected to always exist).

[fabiocos]

@makortel @kpedro88 I would prefer to avoid having for two weeks tests that are "known" to fail. We need to recall to revert the change as soon as the code transition is completed though.

[makortel]

Thanks @fabiocos. I'll then implement @kpedro88's suggestion #22957 (comment) and update the plan in the description of this issue.

[makortel]

Nevermind, while preparing #22977 I realized that the event content to be updated is the output of DIGI step of stage2 workflow, which is always re-done in the matrix workflows. So everything I outlined in the description can be done consistently in one PR without breaking anything or adding temporary workarounds.

Sorry for the noise.