The winter conferences are approaching, where both ATLAS and CMS are aiming to show their latest scientific results with the data gathered in the last year. 2016 saw a huge increase in the size of this dataset, which results in a drastic increase in sensitivity to some of the phenomena we are searching for. A large amount of work goes into understanding this data and ensuring that the models we are comparing it to are accurate. In this post, I am going to describe just one aspect of this process, which I am currently involved in.
We are colliding an enormous amount of protons at the LHC. The frequency with which protons collide when the accelerator is running is far too large to feasibly process and store all information about every single collision. Luckily, there is a trigger system in place, which identifies “interesting” collisions and saves the relevant information for just those. The majority of collisions will be ignored, the triggers will not fire and the information about those collisions will be lost. This is not a big problem, since the physics phenomena that typically take place in these collisions are well understood already.
When do these triggers fire? What is an “interesting” collision? For example, the triggers look for electrons and muons, for objects with very high energy, or for collision events where momentum was seemingly not conserved. The last example occurs when neutrinos are present, since they leave the detectors without a trace. A large amount of seemingly missing momentum could also be a sign of dark matter and other exotic particles.
I am currently involved in deriving corrections for the muon trigger in our simulations at ATLAS. This muon trigger system aims to detect when a collision produced muons. It is not perfect, and will consequently miss some fraction of muons. We can quantify this effect by deriving an efficiency for the trigger. As an example, an efficiency of 90% indicates that on average the trigger will correctly identify 9 out of 10 events that contained a muon. We then compare the efficiency in data to the efficiency in our simulations. If the efficiencies do not agree, we can use this knowledge to correct our simulation.
You may wonder where a discrepancy could come from. For example, certain detector parts may not function correctly while we are collecting data. Imagine a muon being produced in a collision, and then passing through a detector element that was shut off due to a technical problem – we have no chance of identifying this muon, and the muon trigger will not fire! In this case, the trigger efficiency for data (real collisions) will be lower than the efficiency for simulated collisions (where we did not take all possible detector defects into account). My task is measuring and comparing trigger efficiencies for data and simulation. In a second step, I then derive corrections, which are applied to the muon trigger simulation. These corrections resolve potential discrepancies between data and simulation .
Measuring the trigger efficiencies in data and in simulation may sound fairly straightforward, but there is a catch. We can count how many times the muon trigger fired in our data collision events, but how do we keep track of the amount of times when it did not fire, despite there being a muon which it should have identified?
A solution to this problem is known as the “tag and probe method”. We select a second trigger, which we call our “tag” trigger. This trigger should fire based on some property unrelated to the muon  . Our muon trigger becomes the “probe” trigger. The procedure then looks like this:
- Count the amount of collisions for which the tag trigger fired and where there was also a muon produced  : call this amount T
- Count the amount of collisions where the tag trigger fired, there was a muon produced and the probe trigger also fired: call this amount P
The probe trigger efficiency is P/T. Apply this procedure for both data and simulation, compare the efficiencies and derive a correction if required.
To round things off, here is an example of how this works in practice: You can apply the procedure to measure the muon trigger efficiencies in top quark pair production, where the decay products include a muon and a neutrino from a W boson (which itself is a decay product from a top quark). As I mentioned earlier, we can identify such events with a trigger looking for seemingly non-conserved transverse momentum, this will be our tag trigger. We then use a muon trigger as our probe trigger, and finally can calculate the muon trigger efficiencies we are interested in.
Tag and probe in action
Here is a plot showing the method in action with data collected in 2012 :
Ignore everything in green and blue for now, and focus on the top part of the plot first. You can see the muon trigger efficiency in data and simulation (“MC”) as a function of the transverse muon momentum (“Muon pT“). The trigger is roughly 71% efficient in data (shown as triangles with red error bars), and also around 71% efficient in the simulation, shown as red hashed areas. The efficiency does not strongly depend on the muon transverse momentum (the distribution is rather flat). The bottom part of the plot shows the ratio of data and simulation efficiencies, which you can interpret as a correction factor that should be applied to the simulation. In this case, no large correction is required (a correction factor of 1 is equal to no correction).
The results shown in blue on this plot are also obtained using tag and probe, this time targeting muons that originate from a different process: W bosons produced in association with jets. The red results are obtained with top quark pairs, as I described earlier. Finally, the correction factor shown in green is derived from yet another process (Z boson production). As you can see, the correction factors from these three different processes are in good agreement within their respective uncertainties.
 This aspect is important; if the tag trigger shows correlation with the muon trigger, it will bias the conclusions.
 If any trigger fired for a collision event (and it is thus saved), we then proceed to take a much closer look at it. It is possible that the muon trigger missed a muon in an event, but we find the muon anyway when taking this closer look.