Introduction
As you learned in the introduction, all the trigger chains used by ATLAS are defined in the Trigger Menu.
The Trigger Menu configuration is split in two major sections: HLT and L1. As you previously learned, all triggers used for analysis, calibrations, detector diagnosis, or other purposes, are defined within
The configuration for all HLT trigger chains are included in one of the files in the HLT/Menu directory, within the TriggerMenuMT package. Some files in the directory contain configuration functions, but most define one of multiple available Trigger Menus.
Multiple Menus
We define different menus for different purposes and operational periods. Some Menus are meant to be used for data-taking, while other Menus are designed for development and tests. In particular, for heavy-ion data taking and MC production, a dedicated set of Menus are used.
The default proton-proton collisions Menu, where the main set of triggers used for data-taking are defined, is called Physics_pp_run3_v1. This Menu defines all primary triggers for Physics analysis, and the required support triggers for calibrations, background estimation, and performance monitoring.
However, the Physics Menu does not contain many of the dedicated triggers required for luminosity measurements and beam conditions monitoring. Most of these operational triggers, required for successful data-taking in Point 1, are defined in the P1_run3_v1 Menu. This includes many streamer trigger chains which only require a passing signal from the corresponding L1 trigger (e.g. HLT_noalg_L1MBTSA0 for the MBTS detector), or partial-event-building chains recording information from a specific detector as required for some calibrations (e.g. HLT_noalg_laser_TilePEB_L1CALREQ2 used for the laser-calibration of the Tile calorimeter).
Each trigger chain can only be defined once. If a trigger is required in more than one Menu, in order to avoid unnecessary repetition, Menus can be imported into other Menus. As an example, the PhysicsP1_pp_run3_v1 Menu is built from combining both Physics_pp_run3_v1 and P1_run3_v1, as well as adding some additional trigger chains.
You should request a trigger chain to be added to the Menu file that seems the most appropriate for the intended use-case. Make use of the import mechanism!
Chains used for data-taking on previous years, but no longer in active use, are archived in the MC_pp_run3_v1 Menu. This includes, for example, all electron, photon, jet, tau, and MET trigger chains seeded by the Legacy L1Calo triggers. This menu imports Physics_pp_run3_v1, and is used for the Monte Carlo productions at ATLAS, since it contains all triggers ever used for data-taking during the current run.
For the development of new triggers, the Dev_pp_run3_v1 Menu is used, importing MC_pp_run3_v1 (and Physics_pp_run3_v1).Weekly reprocessings of the latest Enhanced Bias dataset are run with the latest Athena release and the Dev Menu, and can be used to compare the performance and rate of the new triggers against any other previously defined trigger.
Special menus are made available for special data-taking conditions, including Cosmics data-taking (Cosmic_run3_v1), and proton-proton collisions with low-pileup (PhysicsP1_pp_lowMu_run3_v1), both also importing P1_run3_v1.
The following diagram shows the import hierarchy for the menus described above:
For heavy-ion collisions, the PhysicsP1_HI_run3_v1, MC_HI_run3_v1, and Dev_HI_run3_v1 Menus are defined.
In preparation for Run 4, development Menus Physics_pp_run4_v1, MC_pp_run4_v1, and Dev_pp_run4_v1 have been defined.
Trigger and signature developers may add triggers to the appropriate Dev Menus as needed for their development work, in consultation with the Trigger Menu Coordinators unless prior explicit authorization has been given. The MC, Physics, and Cosmic menus are only to be modified by Trigger Menu experts. Therefore, to add new triggers, a request by the corresponding signature coordinators to the Menu Coordinators must be sent. No chain shall be changed from Support to Primary without prior authorization.
Since the Menu was moved to version control, the version number suffixes in the Menu names are no longer used, but are still required by the Menu infrastructure. We therefore use the _v1 version number for all Menu names.
In the Trigger databases, both the L1 and HLT menu names still have a version number, used for internal book-keeping. Across different releases of Athena, it is usually the case that two different HLT Menu versions share the same L1 Menu. This is because the HLT Menu and configuration usually iterates significantly faster than the L1 menu.
Remember that Athena doesn’t live alone in Point 1! The software infrastructure involves hundreds of other software packages to configure and interface with the L1 trigger hardware, data acquisition systems, and the monitoring and configuration infrastructure. Therefore, changes such as removing the now unused version suffix may not be as trivial as they seem, and all have to be carefully validated!
Menu structure
Each Menu file contains a setupMenu function, returning a ChainStore object (a dict with some additional consistency checks) that contains all defined trigger chains, grouped by signature and/or slice. Each trigger chain, must belong to their corresponding slice.
We tend to use the terms signature and slice interchangeably. Strictly speaking, a slice can contain one or more signatures, as is the case with the EGamma slice, which contains the Electron and Photon signatures.
For triggers containing only legs of one signature, they must go to their appropriate signature slice (e.g. an electron or photon trigger, belonging in the Egamma slice). However, as it was mentioned before, many triggers combine objects belonging to multiple signatures (e.g. an muon + tau trigger chain, requiring one HLT muon candidate, and one HLT tau candidate, both passing the correct selections for the trigger to be accepted), and therefore much be included in the Combined slice.
Moreover, some slices require scheduling reconstruction and hypothesis algorithms of different slices (e.g. the Bjet slice, which depends on the Jet slice, adding some dedicated b-tagging steps at the end of the chain’s sequence).
If a trigger is not introduced in the correct slice, an error will be produced during the Menu construction.
The slice of a trigger chain is not determined by the L1 trigger employed by the chain! For example, some chains in the Bjet slice use the L1_MU8F_2jJ40_jJ50 L1 trigger. This is also the case with most di-tau primary chains, which include tau + jet L1 triggers.
Menu generation
The generation of the Trigger Menu in Athena is performed following the logic in GenerateMenuMT.py.
First, the L1 Menu is built, validating the definition of all L1 thresholds and items, together with all L1Topo algorithm instances. This is described in details in this section.
After the L1 menu is built, the HLT Menu is generated. HLT execution goes through a step-wise mode, so that at each step a decision is taken whether continue the execution. This has been demonstrated to optimize the execution. In the same way, each chain is split into decision steps.
The base class that represents the chain configuration is called Chain, while the base class that represent the step configuration is called ChainStep, which is described in this session. They are both defined in HLT/Config/MenuComponents.py.
Combined chains are made as combination of chain-legs, each from a specific signature. Merging of legs can be either parallel or serial, and is described in HLT/Config/Utility/ChainMerging.py
Each chain description is collected in a ChainDict as described in the chain construction section and all the chain dictionaries are stored in the HLTMenuConfig singleton defined in HLT/Config/Utility/HLTMenuConfig.py
The generation of each trigger leg is executed following the generateChainConfigs function in the Generate<signature>ChainDefs.py file provided by each trigger signature, according to the information contained in the chain-dict for each trigger leg. For example, the generation of MET legs is controlled by HLT/MET/GenerateMETChainDefs.py.
The generateChainConfigs function allows to map each chain leg’s ChainDict to the corresponding algorithms organized in steps, via a dedicated class <signature>ChainConfiguration that inherits from the base class ChainConfigurationBase (in the MET example this is HLT/MET/METChainConfiguration.py ). The ChainConfigurationBase.assembleChainImpl(flags) is overloaded for each signature, to assemble the chain depending on the information from the dictionary: all the steps are configured here (through the ChainConfigurationBase.getStep()) and collected to finally build the chain-leg in ChainConfigurationBase.buildChain(steps).
In the normal Menu construction procedure, all legs belonging to the same signature in a chain will be grouped together, and sent to generateChainConfigs at once. Each chain part will be constructed individually by the <signature>ChainConfiguration class, but all of them will be parallel-merged together to share the maximum possible number of steps, in order to optimize the runtime. Further alignment routines will result in the reconstruction being performed simultaneously for all legs in all chains which may share the same algorithms, even across signatures (e.g. the fast calorimeter reconstruction in electron and photon chains). This is explained in more detail in the Combined Chains section.
After all individual chains legs are configured, the aforementioned Menu alignment is performed, so that steps shared by multiple chains can be executed simultaneously. This is done by inserting empty steps. Additional empty steps are also introduced during the leg generation itself, so that all legs from the same signature have the same number of steps, to simplify the Menu alignment procedure. If a step is found to be fully empty for all chains, that step is removed. The Menu alignment follows an order to prioritize fast signatures over the slowest once: the order is specified in the the_signature_grouping dictionary, defined in HLT/Config/Utility/MenuAlignmentTools.py, which maps each signature to an alignment group. Signatures in the same group are executed in parallel.
The Menu alignment is described in detail in the menu alignment section.
After the menu is aligned, the decision tree for all the HLT chains is built, and added to the primary HLT sequence, constructed according to the control flow described in the control-flow section.
Finally, the HLTMenu json file is built, containing the complete aligned menu configuration./