Introduction
Combined trigger chains include legs from more than one signature. For example, HLT_e26_2e18_mu12_L1..., containing two electron legs (one with multiplicity 1, and another with multiplicity 2), and a muon leg. Strictly speaking, chains with all legs belonging to the same signature, even if requiring more than one physics object, are not considered combined chains. However, some of the considerations described below for merging legs in combined chains do still apply to multi-leg chains from a single physics signature: all legs belonging to the same signature will always be merged together with a parallel strategy.
These chains present a challenge from the menu alignment perspective, because some signatures share part of the reconstruction steps (e.g. the electron and photon signatures, sharing the fast-calo reconstruction), or depend on the result of of steps executed by another signature, as do some of the MET chains that depend on the reconstructed PFlow HLT jets.
If multiple legs are applying their selection to the same set of candidate reconstructed physics objects, like the e26 and 2e18 legs in the example chain above, then the legs are guaranteed not to overlap due to the uniqueness requirement on each feature, as discussed in the ComboHypo section.
Merging of multiple legs
During the Trigger Menu construction, Chain objects can be regularly merged together. The result of merging multiple Chains is in itself a new Chain object, with ChainSteps containing sequences, ComboHypo algorithms and tools from each of the input legs/parts/chains. The exact topology of this new Chain, and the assignment of the original ChainSteps for each input Chain will be determined by the merging strategy: parallel or serial.
The merging strategy can be specified explicitly in the ChainProp defining the trigger chain in the Menu, but it’s usually let to be automatically handled during the Menu construction, depending on the context at each merge. An additional merging offset can be indicated in the chain’s definition, although it’s normally not explicitly set.
Because the output of a merge step between multiple Chains is a Chain itself, the procedure can be executed iteratively multiple times, using different strategies on each instance, to construct complex combined and multi-leg trigger chains. During the initial construction steps for each of the chain’s parts in GenerateMenuMT.py, calling each signature’s generateChainConfig method, all parts corresponding to the same signature are parallel-merged together.
All the code handling the chain merging logic can be found in ChainMerging.py.
Parallel merging
The easiest way to think about the parallel merging procedure is to imagine a grid of steps, each row corresponding to a different Chain, and each column corresponding to a different ChainStep. Naturally, the result of merging Chains of the same signature will be a new Chain with the same number of steps, because each signature in itself must always produce chains with a fixed step number. If Chains of different lengths are merged, the shorter Chains will be left-aligned on the grid, and right-padded with empty ChainSteps to fill the remaining slots. Therefore, the step grid will always have as many columns as to accommodate the longest input Chain.
Serial merging
Serial merging appends the ChainSteps of each input Chain sequentially, following the alignment group order of the the_signature_grouping dictionary within MenuAlignmentTools.py.
This is currently used to apply a global ordering which delays the start of execution of some chain-legs to only begin after the final step of some other chain-legs. This is done to better optimise CPU consumption by front-loading the execution of chain-legs which are less CPU intensive in order to benefit from their rejection power before the more CPU expensive legs are executed.
The Run 3 menu alignment from 2023 first executes all e, g, mu (including B-physics) and tau legs to completion. It then executes all j, bj and xe chain-legs, where these three signatures are highly coupled in their shared reconstruction configuration. Finally, a second copy of the prior mentioned leptonic selections are scheduled, these are prefixed probe (as in tag-and-probe) and these legs typically reconstruct physics objects with extremely loose (or without) quality requirement cuts. Tag-and-probe chains with one initial tightly selecting “tag” leg and one delayed loosely selecting “probe” leg are one of the methods by which trigger efficiencies may be determined.
Automatic merging
In the automatic merging, all legs belonging to the same alignment group are first parallel-merged together. Then, all alignment groups are merged together serially. The alignment group and order for each of the chain’s signatures is predefined in the the_signature_grouping dictionary.