Conversation
The set comprehension building the per-trigger HLT entries of
keep_columns["cf.ReduceEvents"] was not an f-string, so it added the
literal string "HLT.{trg.hlt_field}" once instead of one entry per
registered trigger.
The effect is currently masked: hbw_trigger_selection's init adds the
same set correctly, and downstream code reads trigger_ids rather than
the HLT path columns. So this is latent rather than active -- it only
bites a selector that does not route through hbw_trigger_selection and
still wants a registered trigger's raw HLT column.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MdTWv3sC68nLDdYw12GV7K
Author
|
@mafrahm fyi |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #155.
The bug
hbw/config/config_run2.py:1397builds the per-trigger HLT entries ofkeep_columns["cf.ReduceEvents"]with a set comprehension that is not an f-string:So it adds the literal string
"HLT.{trg.hlt_field}"exactly once, rather than one entry perregistered
Trigger. One character.Impact — smaller than I first claimed in #155
I originally wrote that this broke what
ComputeTriggerSFasks for. That was wrong, and I wantto correct it here rather than leave it in the issue:
hbw_trigger_selection's init (hbw/selection/trigger.py:188-192) adds the same set,correctly f-stringed, to
keep_columns["cf.ReduceEvents"]. Any selector routing through italready keeps its registered triggers' HLT columns.
trigger_ids— built in the selector attrigger.py:52-134, kept byname at
config_run2.py:1388— not the HLT path columns.require_triggers,masks_dih.py, andhbw/production/trigger.pyare all id-based.So this is latent, not active, and the DL analysis is unaffected. Thanks to @mafrahm for the
trigger_idspoint, which is what prompted the recheck.It bites in exactly one place: a selector that does not route through
hbw_trigger_selectionand still wants a registered trigger's raw HLT column. That is the SL channel, which uses the
year ladder in
sl_remastered.py— I hit it needingHLT.Mu12_IsoVVL_PFHT150_PNetBTag0p53to surviveReduceEventsfor a trigger study.Why fix it anyway
The line does not do what it reads as doing, and the working duplicate in
trigger.pyislabelled
# testing:, so it is not obviously the load-bearing one. Leaving a silently inertcomprehension next to a hand-maintained list of seven HLT paths is a trap for whoever next
assumes registering a
Triggeris sufficient to keep its column — which is what the codeappears to promise.
Worth a separate look (not in this PR): the two mechanisms are redundant, and the
# testing:block in
trigger.pyis arguably the one that should go once this one works.Change
The
fprefix, plus a comment recording that the effect was masked so the next reader does nothave to re-derive it. No behaviour change for DL: the columns it adds are already added by
trigger.py.tests/run_lintingclean.