feat: update TopMuEG skim to latest HLT paths in BTV

[AnnikaStein]

PR description:

• this PR modifies the existing TopMuEG skim by moving to latest recommended HLT paths as suggested by the BTV-POG
• see also recent presentation in BTV-POG WG meeting with relevant slides: here

PR validation:

• a test configuration is added to DPGAnalysis/Skims/test (new test directory created as this is the first DPG / POG skim with a test)
• setup given as follows: skims -s SKIM:TopMuEG --mc --dasquery=file dataset=/RelValTTbar_14TeV/CMSSW_12_1_0_pre2-PU_121X_mcRun3_2021_realistic_v1-v1/GEN-SIM-RECO -n 100 --conditions auto:phase1_2021_realistic --eventcontent=FEVTDEBUGHLT --datatier=RAW-RECO --python_filename=test_TopMuEG_SKIM.py --processName=SKIMTopMuEG --no_exec --era=Run3
• example runs over 100 events obtained from RelVal samples, using CMSSW_12_1_0_pre2
• from the initial 100 events, 3 pass, 97 fail
• for this example, skim reduces file size from 484MB to 19MB

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

@johnalison @soureek

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37574/29323

• This PR adds an extra 20KB to repository

[cmsbuild]

A new Pull Request was created by @AnnikaStein (Annika Stein) for master.

It involves the following packages:

• DPGAnalysis/Skims (pdmv)

@cmsbuild, @bbilin, @wajidalikhan, @kskovpen, @jordan-martins can you please review it and eventually sign? Thanks.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[kskovpen]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-db29cb/23929/summary.html
COMMIT: a2c8361
CMSSW: CMSSW_12_4_X_2022-04-14-1100/slc7_amd64_gcc10
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/37574/23929/install.sh to create a dev area with all the needed externals and cmssw changes.

The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:

• @iarspider Add import test for professor2 #37535
• @cms-tsg-storm HLT menu development #37551
• @smuzaffar added new Utilities/OpenSSL and move unit tests to it #37531

You can see more details here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-db29cb/23929/git-recent-commits.json
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-db29cb/23929/git-merge-result

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 48
• DQMHistoTests: Total histograms compared: 3593033
• DQMHistoTests: Total failures: 5
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3593006
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 47 files compared)
• Checked 200 log files, 45 edm output root files, 48 DQM output files
• TriggerResults: found differences in 3 / 47 workflows

[kskovpen]

Nice work on updating the skim. Could all the "keep" statements in the test fragment be reduced to just a few lines by using more inclusive wildcards or this is not possible?

[AnnikaStein]

Nice work on updating the skim. Could all the "keep" statements in the test fragment be reduced to just a few lines by using more inclusive wildcards or this is not possible?

Thank you for the feedback.

It should indeed be possible to reduce some of the lines by manually combining them with wildcards. However, this test fragment is just the result of using the TopMuEGPath as part of DPG skims which automatically produces this list of keep and drop statements. Maybe it would then make sense to keep it as it is, allowing comparisons with related test configurations of other DPG skims. If I understand correctly, this is a fundamental difference with respect to PAG skims, where the EventContent / keep / drop is defined individually per test configuration, because the use case is different.

Should we decide to still manually adapt the keep / drop statements explicitly to our needs and simplifying or reducing them, this would also be an opportunity to check with all experts involved which branches are of interest. (Tagger outputs? Tagger inputs? Different generations of taggers?)

[kskovpen]

Thanks for the explanations! I think this is fine, unless @cms-sw/orp-l2 have other suggestions.

[qliphy]

Thanks for the explanations! I think this is fine, unless @cms-sw/orp-l2 have other suggestions.

fine with me.

[kskovpen]

+pdmv

[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, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[qliphy]

+1