Skip to content

Decorate HLT BTagging containers with links to jets in slimmed navigation [ATR-29934]

Teng Jian Khoo requested to merge khoo/athena:main-DerivationFwk-HLTBtagMatch into main

With the slimmed Run 3 trigger navigation, we can compactly save four-vectors to perform trigger matching on all IParticle object types. One aspect that is missed here is the ability to associate b-tagging working points with b-tagged jets.

This is an attempt to save the requisite information efficiently in DAOD_PHYS. We should not link from the slimmed four-vectors to the b-tagging container or decorate with b-tagging info as this decorates every four-vector in the navigation. Instead, when jet features are remapped, we can retrieve any associated b-tagging object and create a link in the opposite direction. Saving this link and just the necessary b-tagging probabilities keeps the payload about as small as is practical.

We could go a step further and reduce the pb,pc,pu to a single float by decorating on the discriminant value, but this would require reproducing the discriminant calculation with a configurable f_c parameter (ideally per discriminant) and in addition we also have dl1dbb and potentially other variants which may have non-standard discriminants.

To avoid conditional decoration, we need to specify the list of HLT b-tagging containers to be decorated -- there is currently only one. In principle we might be able to make some more robust checks e.g. by comparing the containers linked from jets to the list of expected containers. I also stuck to a conventional Decorator rather than WriteDecorHandle because firstly there is not really expected to be any downstream dependency, and in the first attempt managing the locking interaction with another conventional Decorator was unsuccessful, but a more sophisticated handling is probably possible.

TODO:

  • Verify that persistified links actually point where we expect them to point
  • Fix syntax for output branches
  • Determine size of additional HLT b-jet containers
    • On 100 ttbar events, I get 0.289 kb/evt with the currently added content
    • Most of the size is due to the b-tagging probabilities, so if we are selective about which we keep (e.g. only recommended tagger per year) this could be cut down a fair bit.

Some folks who may be interested: @arelycg @wbalunas @dguest @lshi @boliu @tamartin @mrimoldi

Edited by Teng Jian Khoo

Merge request reports