keep_columns drops two registered DL trigger paths: missing f prefix in config_run2.py

[artlbv]

Branches: HH_HHH_incl_2024 and master (byte-identical on both).

hbw/config/config_run2.py builds keep_columns["cf.ReduceEvents"] and ends with a set
comprehension that is meant to keep one HLT.* column per registered Trigger:

} | {
    "HLT.{trg.hlt_field}" for trg in cfg.get_aux("triggers", [])
}

It is missing its f prefix. The comprehension therefore evaluates to the single literal string
"HLT.{trg.hlt_field}", and no registered trigger's column has ever been kept through it. Only the
seven hand-listed HLT.* entries above it work.

What this costs the DL channel today

add_triggers registers eight triggers for is_dl. Two of them are not in the hand-listed seven:

• HLT_Ele50_CaloIdVT_GsfTrkIdT_PFJet165 (single_e50_noniso, id 203)
• HLT_DoubleEle33_CaloIdL_MW (di_e33_noniso, id 204)

Both are dropped at cf.ReduceEvents.

The selection is unaffected — hbw_trigger_selection runs inside cf.SelectEvents, where the full
HLT collection is still there. What breaks is everything downstream of reduction that reads the
paths back. Concretely, hbw/trigger/trigger_prod.py is a Producer, so it runs in
cf.ProduceColumns, and it does

self.uses.add(f"HLT.{trigger.hlt_field}")

over config_inst.x.triggers (:541, :567). So trigger_prod_dl — and therefore
hbw.ComputeTriggerSF — is asking for two columns that reduction did not keep.

Verified

On c24v15 / hbw_dl, cfg.x.keep_columns["cf.ReduceEvents"]:

before:  HLT.Ele23_Ele12_..., HLT.Ele30_WPTight_Gsf, HLT.IsoMu24, HLT.Mu12_TrkIsoVVL_...,
         HLT.Mu17_TrkIsoVVL_..., HLT.Mu23_TrkIsoVVL_..., HLT.Mu8_TrkIsoVVL_...,
         'HLT.{trg.hlt_field}'          <-- the literal
after:   the same seven, plus HLT.DoubleEle33_CaloIdL_MW and
         HLT.Ele50_CaloIdVT_GsfTrkIdT_PFJet165, and no literal

Fix

Add the f. Once it works, the seven hand-listed entries become redundant for every path that is
also a registered Trigger, which is five of them.

I have this fixed locally on a fork branch and am happy to open a PR against HH_HHH_incl_2024
(artlbv/hh2bbww@be9f94a) — flagging it here first because the two dropped paths are DL ones and
you may want to check whether anything in the DL trigger-SF chain has been quietly working around
it. Found while reviving the SL channel for an MC-only TOPO-trigger sensitivity study, but it is
independent of that work.

[artlbv]

Correction to the impact assessment above, after a discussion with a developer.

The DL analysis is not affected, and my claim that ComputeTriggerSF was requesting dropped
columns was wrong. Two things I missed:

1. hbw_trigger_selection's init (hbw/selection/trigger.py:188-192) already adds
   f"HLT.{trigger.hlt_field}" for every registered trigger to
   keep_columns["cf.ReduceEvents"] — correctly f-stringed. Any selector routing through it
   keeps those columns regardless of the broken comprehension.
2. Downstream consumers use trigger_ids, not the HLT path columns. It is built in the
   selector (trigger.py:52-134, where raw NanoAOD is available) and kept by name at
   config_run2.py:1388. require_triggers, masks_dih.py and hbw/production/trigger.py
   are all id-based.

So the bug is latent: it only bites a selector that does not route through
hbw_trigger_selection and still wants a raw HLT column — i.e. the SL channel with its year
ladder, which is how I found it.

Still worth fixing, since the line does not do what it reads as doing and the working duplicate
is labelled # testing:. PR: #156.