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 MenuSequence
s, 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 MenuSequence
s.chainDicts
: list of ChainDict
s 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). 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 MenuSequence
s 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 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 ChainStep
s (one for each chain).
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.
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 ChainStep
s 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.