TriggerMenuMT package
A prescale is a number that defines what fraction of events we keep out of all possible events that would have passed the trigger requirements. Each trigger comes with two associated prescales: an L1 prescale (L1PS) and an HLT prescale (HLTPS). These are applied in subtly different ways, though the distinction is very important.
Note that a prescale of -1 means that a trigger is disabled (never passes any events), and a prescale of N > 1 means that we want to select only 1 in N events. Triggers with a prescale of exactly 1 are often referred to as unprescaled, and triggers with a prescale N>=1 are often referred to as enabled.
The pathway of an event through the trigger system is roughly as follows:
TBP: trigger before prescale (did this item pass the event, irrespective of what the prescale is?)TAP: trigger after prescale (did this item pass the event, after we take into account the prescale that we configured in the menu)TAV: trigger after veto (and after prescale, i.e. this is the TAP after the deadtime veto). In recorded data, TAP and TAV will always be the same because we only record events after the deadtime veto is applied.As an example, let’s consider a menu where we have the L1 item L1_MU10 enabled with PS=2. This means we only want to select one in every 2 events that could otherwise pass the trigger. In our toy example, we have two events, both of which have at least one MU10 threshold present. Thus, the CTP will set the TBP bit to 1 for both events. However, in each event a random generator is used to decide if the event should pass given that PS=2. On average, only one of our two events will end up with TAP=1, while the other will have TAP=0. To first order, the TAV bit will equal the TAP bit, because we only lose a small fraction of events to deadtime.
One very important caveat to note is that when L1 items are disabled they will still have a valid TAP that appears to be configured with PS=1. This is because disabling is a separate procedure to prescaling. Also checking that PS>0 will ensure that the decision from TAP also includes the possibility that the item was disabled.
The HLT reads the input L1 decisions and activates the HLT triggers for which the necessary L1 items were passed and the HLT should run (i.e. the HLT item is enabled). HLT prescales are applied, so we only run the HLT reconstruction on events where we might eventually want to record the event. This is an important point that often confuses people, since it is different from L1 prescales.
At L1, prescales are applied after the L1 decisions are computed, because the CTP is fast and this is easy to do. To make the most of our HLT farm, we apply HLT prescales before the trigger runs. Thus, it is not possible to know in any given event whether or not a trigger would have passed, if had not been for the prescale, without emulating/rerunning/deducing the decision by some other method. Thus, there is no TBP equivalent for HLT decisions.
NB: understanding the deadtime veto is beyond the scope of this document, unless an informed reader would like to add it.
Prescales are defined in L1PrescalesSet and HLTPrescalesSet files. Default prescale sets are generated when you compile the menu, but these do not correspond to what we run online!
When compiling the menu, the TriggerMenuMT package also generates some additional prescale files named TriggerValidation or BulkMCProd. These just disable certain very high CPU triggers that are only useful online anyways - unless you are a menu expert generating MC keys or someone requesting keys for MC production, you do not need to pay attention to these.
The real prescales we run online are determined with the TrigMenuRulebook package.
"HLT_2mu14_L12MU10": {
"name": "HLT_2mu14_L12MU10",
"counter": 153,
"hash": 2619091790,
"prescale": 1,
"enabled": true
},
Most of the time, L1 items are shared by multiple HLT items. Online prescales are configured in a way such that the L1 TAP rates are as low as possible. As much as we can, the prescales are pushed to L1 so we do not waste L1 rate that we won’t use at HLT anyways!
For example, if we have two triggers HLT_mu15_L1MU10 and HLT_mu10_L1MU10, with rates as in the table below:
| Trigger | Unprescaled rate | Target rate | Total prescale | L1 prescale | HLT prescale |
|---|---|---|---|---|---|
| HLT_mu15_L1MU10 | 100 Hz | 20 Hz | 5 | 5 | 1 |
| HLT_mu10_L1MU10 | 200 Hz | 20 Hz | 10 | 5 | 2 |
You can see that HLT_mu15_L1MU10 requires a total prescale of 5 to achieve the target rate, while HLT_mu10_L1MU10 requires a total prescale of 10. We can’t prescale L1_MU10 by any more than 5, because then we wouldn’t be able to get enough rate for HLT_mu15_L1MU10. Thus, we can push the L1_MU10 prescale to 5, and the remaining prescale for HLT_mu10_L1MU10 needs to be applied at HLT.
The TrigMenuRulebook package optimizes the L1 prescales such that they are always as high as possible. A simple way of summarizing it is the following: every single L1 item should (and must!) have an HLT item that runs unprescaled.
Note that, in special cases, this could be an HLT trigger seeded by a composite L1 item, like L1_All (so it might not be immediately obvious from scanning through a prescale json file!)
NB: this is a toy example - these rates, items, and prescales are fake.
Now let’s imagine we have the following scenario:
| Trigger | Unprescaled rate | Target rate | Total prescale | L1 prescale | HLT prescale |
|---|---|---|---|---|---|
| HLT_mu20_L1MU10 | 40 Hz | 8 Hz | 5 | 5 | 1 |
| HLT_mu10_loose_L1MU10 | 180 Hz | 2 Hz | 90 | 5 | 18 |
| HLT_mu10_medium_L1MU10 | 160 Hz | 2 Hz | 80 | 5 | 16 |
At HLT, we’ll need to reconstruct 20 GeV muons in the MU10 RoIs in all events passing L1_MU10 after prescale. We only need to reconstruct 10 GeV muons in 1/18th and 1/16th of the events for the mu10 triggers. If we let the HLT randomly prescale each HLT trigger independently, we’ll run on 1/18 + 1/16 - 1/18*1/16 = 11% of the events. However, we can restrict the 1/18 events to be a subset of the 1/16 events by coherently prescaling the two items, so that we’re only running on ~6% of the events.
Note that coherent prescales are an HLT-only feature, and all coherently prescaled triggers must share the same L1 item. Whether or not a coherent prescale is the right choice for a given set of triggers depends on whether or not the subsets of events they select need to be independent or not. In most cases, coherent prescales are preferred.
This is a limitation of the L1 system.
TriggerMenuMT packagePrescales are configured in two main places. The first of these are the prescale sets defined inside TriggerMenuMT. These are for MC production, to ensure that we’re not running e.g. CPU-intensive beamspot or minimum-bias triggers on every ttbar event. These are also used for data reprocessings, where we check rate and cost, for the same reason: the jobs will have trouble completing on the grid if we run triggers designed for low-pT on every enhanced bias event.
However, these prescale sets only turn triggers on or off (i.e. PS = -1 or PS = 1): you wouldn’t want one of your supporting triggers prescaled by 5 in MC, artificially reducing statistics! Instead, the pileup reweighting tool and lumi calculator allow you to prescale MC to match the luminosity and distribution of average interactions per crossing collected by the prescaled trigger.
Online prescales are generated by TrigMenuRulebook. This package exists outside athena because it is not tied to a release and is subject to far more frequent updates than suitable for the MR system. The rulebook, as we colloquially call it, takes a set of prescale rules per trigger and compiles them all (according to the principles outlined above) into a consistent set of prescales at L1 and HLT contained in respective JSON prescale files.
TriggerMenuMT and their purposesThere are three prescale sets defined in the menu, listed below. These names took the place of the old tightperf, tight, loose prescales whose names were not overly informative. When generating e.g. an SMK for MC production, it’s important to make sure you have the correct prescale set - otherwise the necessary triggers might not be included!
Note that these prescales only disable triggers at HLT: there is no disabling of L1 items, because simulating L1 items is not a bottleneck in our reconstruction.
You can also generate a “default” prescale set: [list what this contains]
BulkMCProdThis is the prescale set that we use to generate nearly all MC designed for analysis. There can be some exceptions, though!
This prescale set contains all the triggers enabled in BulkMCProd plus a few more that are necessary for CP studies.
This prescale set contains all the triggers enabled in BulkMCProd and CPSampleProd, plus a few more that are necessary or experts to validate certain algorithms, but not necessary for most users.
«rough explanation to go here»
link should go here.