-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TriggerResultsFilterFromDB
: accept all triggers paths in presence of an empty list of expressions
#46833
TriggerResultsFilterFromDB
: accept all triggers paths in presence of an empty list of expressions
#46833
Conversation
…an empty list of expressions
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46833/42853 |
A new Pull Request was created by @mmusich for master. It involves the following packages:
@Martin-Grunewald, @cmsbuild, @mmusich can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
+1 Size: This PR adds an extra 16KB to repository Comparison SummarySummary:
|
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. @antoniovilela, @sextonkennedy, @rappoccio, @mandrenguyen (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
In PR #42965 (and similarly more recently in #46742) few AlCaReco producers were changed such that
TriggerResultsFilterFromDB
is employed instead ofHLTHighLevel
to select events.The two behave differently in presence of an empty logic expression:
HLTHighLevel
selects all events (filter effectively is ignored), whileTriggerResultsFilterFromDB
accepts none.The goal of this PR is to make the behaviour uniform among the two. This is particularly convenient because the empty expression list is very common in many
eventSetupPath
keys across different Global Tags and it would avoid to make massive clean-up campaign.While this PR changes the behaviour of the module I couldn't find any other consumers of it other than named AlCaReco producers, so it should be safe to do.
PR validation:
Used the configuration file obtained from the following cmsDriver command (borrowed from this JIRA ticket and the stats2 link therein) that used to produce an empty dataset:
#!/bin/bash -ex cmsDriver.py step3 \ --conditions 141X_mcRun3_2024_realistic_HI_Candidate_2024_11_19_14_38_08 \ --datatier ALCARECO \ --era Run3_pp_on_PbPb_2023 \ --eventcontent ALCARECO \ --filein /store/relval/CMSSW_14_1_6/RelValHydjetQ_B12_5362GeV_2024/GEN-SIM-RECO/141X_mcRun3_2024_realistic_HI_Candidate_2024_11_19_14_38_08_MinBias_2024HIN_noPU_RV257-v2/2590000/0052ce44-83\ da-4782-b2f7-3e16e58e42be.root \ --fileout file:step3.root \ --nStreams 1 \ --nThreads 8 \ --no_exec \ --number 100 \ --python_filename step_3_cfg.py \ --step ALCA:TkAlMinBias+SiStripCalMinBias
and verified that there are events in output, where the same command without this PR produces a file without any events in it.
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:
Not a backport, might be backported.