Skip to content

[ATR-23807][ATR-23688][ATR-23421][ATR-23817] Jet and Bjet refactor ComboHypo Leg Restrictions

Tim Martin requested to merge tamartin/athena:comboHypoInputFiltering_4 into master

This large MR bundles a number of changes which apply a small number of QOL fixes to jet, plus some real bug fixes to bjet and jet+other chins.

  • Jet have a special case handling - only one HypoTool per Chain to cover all jet legs. This differs from the standard behaviour of one HypoTool per chain leg.
  • The jet special case is refactored. Multi-leg chains with 2+ jet legs (bjet legs count too) now obtain the correct number of legXXX chainDicts, before we only ever created one. The chainPart section of each one remains identical (this contains the data for all of the jet legs letting the single HypoTool still configure correctly)
  • The implementation of the special case moves to the HypoTool factory. This will sense when it is being asked to return a HypoTool for the 2nd+ jet leg and return None
  • We return to all chains being of equal multiplicity in each step. This fixes two bugs with bjet chains, firstly it means that jet-only legs propagate also into the bjet step and are registered as having passed the event (should bjet pass), secondly it keeps the leg numbering aligned between the jet and bjet steps, otherwise bjet run on the wrong legs for some chains!
  • The jet HypoTool is modified to not add its ChainID. This is because a) it doesn't need to do so any more and b) in a multi-leg chain setup, what it thinks is its ChainID is now actually its first leg ID. And adding this to all chains is a bug.
  • The above changes normalise the jet and bjet configuration such that adding any other arbitrary legs from other slices is now expected to work, e.g. HLT_e22_2j20_j40_mu20_xe50 would now be expected to work. The only constraint is that the jet and bjet legs have to be contiguous, HLT_j20_e22_j40 would not be allowed.
  • The PassthoughComboHypo is deleted and replaced with the actual ComboHypo in jet Steps.
  • The ComboHypo will now add the ChainID to the jets on passing chains, this is in line with all other chains.
  • The ComboHypo now knows the multiplicity required for each jet leg. We do not want to cut on this in the ComboHypo as the jet hypo has (for example) the SHARED concept (the ability for a jet to simultaneously satisfy multiple legs) which the ComoboHypo does not. We add a new noCombo decoration to the jets to communicate to the ComboHypo that multiplicity cuts are not to be re-applied for objects on these specific legs.
  • The ComboHypos is, however, able to use the jet multiplicity in conjunction with any ComboHypoTools which wish to apply additional combinatorial selection over the selected jets, the first candidate here is m_jj AFP-jet.

All of the above leads up to ...

  • The ComboHypo's addInput python config function is now called once per leg after the above jet fixes.
  • This call data is used to associate each leg to a given input collection, a mapping is needed as multiple legs may share the same input collection, which is only registered once.
  • The ComboHypo starts to restrict each chain-leg to only accepting incoming DecisionObjects from this single input collection, rather than from any input collection.
  • This fixes a bug with multi-leg chains where two or more legs share the same input collection, and there is at least one EMPTY leg step somewhere. Up to now, the non-empty leg was able to be satisfied by the DecisionObjects coming from the previous step - these DecisionObjects were propagated forward for the purposes of continuing the EMPTY leg only. Them satisfying other legs was a bug.

The count changes have been explored on event-by-event basis in the above linked JIRA

Edited by Tim Martin

Merge request reports