Draft: Move trigger smart content lists into DerivationFrameworkTrigger

The DerivationFrameworkCore package really should not host more than essential DF infrastructure code. I suspect the trigger code went here because we didn't (want to) have a separate package for trigger DF code until now. As we have DerivationFrameworkTrigger now, we should put the trigger smart slimming code here.

One file, HLT_xAOD__MuonContainer_MuonEFInfoCPContent.py is not referenced anywhere in the repo, so was removed.

There are some other changes that would be good to do before merging:

• AdditionalTriggerContent should be renamed to something more explicitly indicating that it is for Run 2 ID trigger content (or be merged with TrackingTriggerContent.py with some selection capability
• Conversely, it would be good to merge the JetTrigger*Content.py files
• We should establish if any of the FixContent is needed, and/or if any of the Include*TriggerContent flags are never used
  • IncludeEtMissTriggerContent is only true for DAOD_PHYSVAL
  • IncludeMinBiasTriggerContent is only true for DAOD_PHYSVAL
• We should work out from which derivation formats are still being created from 25.0 which of the options are actually needed, and use that to clean up anything that isn't

As I believe PHYSVAL now ought to just include the full (ESD) trigger EDM anyway, there is no need to preserve the flags that are unique to that format, and all of those can be removed. I'd also be inclined to remove all the False settings, as they just create noise in searches, but that would be a big mechanical task over all formats, which could be factorised.

changed the description

changed the description

Maybe it is time to get rid of the hard-coded lists entirely?

We now have addTrigEDMSetToOutput integrated into the smart slimming list.

We could e.g. make something like IncludeEtMissTriggerContent call addTrigEDMSetToOutput at AODSLIM verbosity level and additionally filter on category = "MET"

That's an intriguing prospect... I like it in general, but does it have the risk of being too inclusive, given the evolution of containers over time? Maybe we should survey precisely who (still) needs what?

Ah, I suppose choosing the EDM level helps to address the granularity, and might make for an even nicer interface. It's tempting to wipe the flags, and work with something a bit more freeform (documented, of course), e.g.

# Provide a map of category to level
SlimmingHelper.IncludeTriggerContent(
  {
    "MET": "AODSLIM",
    "UTT": "AODFULL",
  }
)

We could then keep around a few static lists for specific purposes, e.g. the b-jet trigger matching.

(I also don't really like the flags. Doubly so as all they do in practice is to inject a string into the SmartCollections list)

added 2 commits

• aa2d8e81 - Include Aux content in TriggerSlimmingHelper.addTrigEDMSetToOutput
• 65a32c63 - Clean up unnecessary/unused code adding trigger content

Compare with previous version

added 1 commit

• b24bb836 - Consolidate BJet & Muon trigger content in DerivationFrameworkTrigger

Compare with previous version

added 1 commit

• 4fdfdd64 - Rename InDet Trigger smart content lists

Compare with previous version

marked the checklist item AdditionalTriggerContent should be renamed to something more explicitly indicating that it is for Run 2 ID trigger content (or be merged with TrackingTriggerContent.py with some selection capability as completed