Chain Steps

Last update: 22 Oct 2024 [History] [Edit]

The Chain step

The HLT execution is splitted into decision steps, each providing the OR of the decision steps of all chains: if at least one chain has passed the step, the execution continue to the next one.

Multiple chains can share the same step, e.g. the fast calorimeter reconstruction step for an electron and photon trigger, sharing its reconstruction with all other electron and photon triggers seeded by the same L1 RoI. The Menu alignment takes care of ensuring that the step execution is scheduled only once. For alignment purposes, remember that all chains from a given signature must have the same number of steps. Therefore, if a chain variation only requires a subset of steps to be executed (e.g. an energy calibration tau trigger, without tracking or identification steps), empty steps have to be included in their place.

Each Chain then functions as a list of ChainStep objects. A step is made of a single MenuSequence if the chain consists of only a single leg, while a combined chain is made of multiple MenuSequences, one per leg.

In the control-flow, a step for a chain is always bookended by a single Filter Algorithm and a single ComboHypo algorithm, which checks the pass status of all of the legs of the chain together (see the Control Flow section for more details). In-between these may be multiple reconstruction sequencers and Hypo algorithms, depending on the number of legs the chain has.

The ChainStep class is defined in MenuComponents.py, with the following default interface:

ChainStep(
    name, 
    SequenceGens = None, 
    chainDicts = None, 
    comboHypoCfg = ComboHypoCfg, 
    comboToolConfs = None, 
    isEmpty = False, 
    createsGhostLegs = False
):

These are the parameters:

  • name: identifier of the step algorithm content (used critically in the ControlFlow because it gives name to the FilterAlgorithm); steps with the same name can exist with the same algorithms, but different ChainDict (see note below)
  • SequenceGens: list of functions to generate the step MenuSequences.
  • chainDicts: list of ChainDicts of the step legs (one entry per leg). Exception for jet steps, which have the full ChainDict of the chain because combinations are handled internally.
  • comboHypoCfg: the function to generate the comboHypo configuration (default is a generic ComboHypo).
  • comboToolConfs: ComboHypoTools, if different from the default.
  • isEmpty: flag to identify empty steps (needed for the alignment).

tip The ChainStep object is a container to group the information of a step in a specific chain. Since it contains the chain-dictionaries of the legs, there can be more instances of steps with the same name, that are owned by different chains. This means that a ChainStep object is not shared between chains. During the Control Flow creation, these multiple ChainStep instances are merged, so that it will result in a single AthSequencer containing the step sequences, for which the HypoAlg and the ComboHypo will have tools corresponding to each individual Chain.

Fortunately, most of the times you won’t need to interact with the ChainStep objects themselves. In practice, when you define the signature-specific XXXXChainConfiguration class (subclassing ChainConfigurationBase), each call to

getStep(
    flags, 
    stepName, 
    sequenceCfgArray, 
    comboHypoCfg=ComboHypoCfg, 
    comboTools=None, 
    **stepArgs
)

will create a ChainStep object, based on the step’s sequence defined by the MenuSequence objects, themselves returned by the functions in the sequenceCfgArray list. Common practice is to define a function for each step’s major variation (e.g. standard vs LRT track reconstruction in a tracking step), to which the additional arguments (stepArgs) will be passed for the step’s overall configuration. For example,

return self.getStep(flags, stepName='Precision_tau', sequenceCfgArray=[tauPrecisionSequenceGenCfg], is_probe_leg=is_probe_leg, tau_id='GNTau')

ComboHypo algorithms are executed at the end of the ChainStep (after the individual leg HypoAlgs are executed). They and their respective tools can be indicated through the comboHypoCfg and comboTools arguments. Most custom multi-object requirements will add comboTools to the default ComboHypo instantiation. Only very rarely (e.g. B-physics & light states) is a fully bespoke ComboHypo applicable, and a bespoke comboHypoCfg is provided (see this section).

The MenuSequences are generated only when createSequences() is called, which is done only once in the job, during the createDataFlow function execution. This means that multiple ChainStep instances will ultimately result in a single AthSequencer in the Control Flow, for which the HypoAlg and ComboHypo will have tools corresponding to each Chain.

The Menu sequence

The MenuSequence class groups the reco sequences with the Hypo algorithm and its HypoTools. It is defined in MenuComponents.py and this is the default interface:

MenuSequence(flags, selectionCA, HypoToolGen, globalRecoCA=None)

It contains the generator functions of the configurations of all the algorithms and sequences for the execution of the chain-leg. The reco algorithms and tools, and the HypoAlg are collected in the selectionCA passed as one of the parameters.

A MenuSequence is identified by a unique name, which is inherited from the HypoAlg’s name. As suggested before, multiple chains usually share a reconstruction sequence, which means they will use the same MenuSequence (sharing all its algorithms) in different ChainSteps (one for each chain).

tip The Gaudi steering is able to avoid multiple executions of the same algorithm, and in principle a MenuSequence (which is not using EventViews) can appear also in different step positions. But it will still only ever execute once. Algorithm instances which have such duplications in multiple steps must only depend on input collections which are created prior to (or equal to) the earliest step in which the algorithm is added.

All algorithms and sequences are represented as AlgNode objects. The AlgNode is a Node with a Gaudi algorithm/sequence configuration as content. The Node is a base class containing input and output links, useful to connect the elements in the dataflow as a graph. For an AlgNode the connections are the xAOD::DecisionContainer DataHandles of the algorithm. Each class of algorithms useful for the dataflow have their representation as AlgNode (for example InputMakerAlgNode, HypoAlgNode, FilterAlgNode, …).

Each MenuSequence owns these elements:

  • InputMakerAlgNode, for InputMaker/EventViewCreator,
  • AthSequencer node, the top sequence of the selectionCA,
  • globalRecoCA, a CA for algorithms that run globally,
  • HypoAlgNode, for the HypoaAlg,
  • HypoToolGen, the function to generate the HypoTools.

Similar chains sharing a MenuSequence will still have particular selections to be applied to the reconstructed objects and the calculated quantities (e.g. thresholds, ID working points, etc…). This is handled by the HypoTools, configured separately for each chain by the HypoToolGen function, with the signature:

TrigXXXXHypoToolFromDict(flags, chainDict)

where the chainDict contains the particular chain information.

The MenuSequence class is able to create its internal dataflow within the sequence (in the __init__, it connects the InputMaker and the HypoAlg) and to connect the InputMaker to the step’s FilterAlg (connectToFilter).

For alignment purposes, an EmptyMenuSequence class also exists to be used in Empty steps, which emulates a reco sequence with no HypoAlg. It contains an InputMaker and an empty sequence, used for merging, to follow the same MenuSequence behaviour.

Verifying chain sequences

In Athena’s logfile, and in the json Menu files produced during the Menu construction, the final aligned and combined structure for all chain steps can be found. All step names are prefixed by Step#, with the corresponding step number, e.g. Step1_MVA_tau for any single-tau chain.

In the HLTMenu.json file you can quickly find the complete list of ChainSteps that are to be executed for each trigger, in "chains" -> "<chain-name>" -> "sequencers". For multi-object chains with, you will find the merged sequences instead, with the exact algorithm being executed on all of the legs on each step, e.g. Step1_merged_MVA_tau_MVA_tau. If the legs belong to different signatures, or don’t share the entire reconstruction, you will see merged steps with possibly empty sub-sequences, e.g. Step17_merged_EmptyAllProbeAlign1_Electron_MVA_tau from an electron+tau chain. More information and examples of combined chains sequences are shown in the Combined Chains section.

Details for each step’s sequence (filter algorithms, view creation algorithms, reconstruction sequence, Hypo alg., and ComboHypo alg.) are shown Athena’s logfile. For example, in the case of Step1_MVA_tau:

Step1_MVA_tau [Seq]  [Sequential]  [Prompt] 
  FStep1_MVA_tau [Alg]  [n= 0]
  Step1_MVA_tau_reco [Seq]  [Concurrent]  [OR] 
    CaloTau [Seq]  [Sequential]  [Prompt] 
      IM_tauCaloMVA [Alg]  [n= 0]
      ROBPrefetchingAlg_Calo_IM_tauCaloMVA [Alg]  [n= 0]
      tauCaloMVAInViews [Seq]  [Concurrent]  [OR] 
        tauCaloMVARecoVDV [Alg]  [n= 0]
        TauHLTCaloCellMaker [Alg]  [n= 0]
        TauHLTCaloClusterMaker [Alg]  [n= 0]
        TauCaloRoiUpdater [Alg]  [n= 0]
        TrigTauRecMerged_TauCaloOnlyMVA [Alg]  [n= 0]
  TauL2CaloMVAHypo [Alg]  [n= 0]
  ComboHypo_Step1_MVA_tau [Alg]  [n= 0]

The algorithm list (and the type of each algorithm) can also be retrieved from the "sequencers" -> "<step-name>" section of the HLTMenu file (as a summary in a flattened list, rather than the original tree structure). More details can be found in the Control Flow section.