Reconstructing based on interactions from simulated ATLAS data
The is a neutral, massive vector boson acting as the force carrier of the weak nuclear force,
along with its charged partners, the . Given its large mass, it decays too quickly to be
observed directly. It decays primarily to pairs of quarks(1), but because quarks will instantly
create jets of mesons and baryons, it will get very messy and it is difficult to extract anything
meaningful out of it. It is therefore more useful to look at decaying to pairs of charged
leptons, for example or . In this case we shall be looking at decays to .
Using a sample of around 10 000 simulated events from the ATLAS detector at
CERN, we can analyse the outgoing muons and reconstruct the . Because of energy and
momentum conservation, if you can measure the energy of the muons and sum them
together, you can calculate the invariant mass of the .
All variables we will discuss are assembled in a tree, which is then filled with the
data as the algorithm loopes through the events.
The tree is filled by first clearing the variable from the last event, and then updating it with
the new value.
The first objective is to find out how many muons are in each event.
Figure 1: Number of muons produced in each event, muons along x-axis, events along y-axis
As expected, most events contain exactly two muons, but there are also several events
containing zero or one muons, as well as many events with more than two, some events
containing as many as six to seven muons. We know that there should be exactly two muons in each
event, therefore the other muons must come from somewhere else. Possibly, they show up because one of the muons
could create multiple tracks, either in the inner detector, or in the muon spectrometer. This means
one muon could be registered more than once, which we have to take into account when looking at the rest
of the data. The events containing less than two muons show up because muons can escape outside the detector
range and be lost. In order to proceed with the rest of the data, we must ingore these events,
because this will mess up the process later.
We can do this by using a simple if-statement:
This will fill the tree with the size only and then terminates the loop for that event
if it contains too few muons. The rest of the data for the relevant muons can then be filled later
without worrying about messing up the plots.
Next, looking at the pseudo-rapidity () of the muons:
Figure 2: Pseudo-rapidity of the muons
There are two clear peaks around .
Pseudo-rapidity is defined as
This means that most muons travel in a direction , with
theta being the polar angle relative to the beam axis. Normally we would expect this to be flat, but
because we are looking at a pure sample with only , it tends to have a bias
in the eta-distribution, because the decays will be biased towards a particular eta direction.
Looking at the azimuthal angle in the plane perpendicular to the beam
Figure 3: Azimuthal angle phi of the muons
There are no clear peaks here, suggesting that the trajectories in this plane are mostly
random, but this is expected. Given that the goal is to reconstruct the
, it is more interesting to look at the transverse momentum (),
which is the component of the momentum perpendicular to the beam axis.
Figure 4: Pt from all muons
Looking first at the for all the muons in the sample, there is a clear peak around
GeV, which should be around half of the mass. Worth noting here, that a lot
of muons with very low momentum, GeV are registered here. These are presumed to
be the muons that are measured multiple times in the different detectors, as talked about earlier. To avoid
these, we can filter them out by only looking at the leading and sub-leading muons, which
are the two muons with the highest in each event.
This will select the leading and sub-leading by updating a running variable and assigning the
relevant muons to a pair of pointers.
Figure 5: Pt for just leading muons
Looking at the of the leading muon there is the same clear peak around GeV,
but the low muons have completely gone.
Figure 6: Pt for just sub-leading muons
For the sub-leading muons we also have a peak around GeV. The
reason it is slightly smaller than for the leading muons is because any transverse momentum for the
translates to one muon having more than the other. Here, there is also a small peak of
the irrelevant muons as well, although it is much smaller than for the full set of muons, as the
vast majority of those were avoided by only looking at the leading and sub-leading muons. Using
the from the leading and sub-leading muons, we can create a scatterplot, to see how the
values are distributed.
Figure 7: Scatterplot with leading muon Pt along x-axis, sub-leading muon Pt along y-axis, and number of events
indicated by colour
Here, it is clear that the peaks for the values are at around 40-45 GeV, which is to be
expected given the peaks observed in the previous histograms.
Figure 8: Total energy of muons
The peak in also lines up with a bump in the plot of the total energy of the muons
produced, which is at around GeV. The reason it is a bit higher than for is
because the presumably has some kinetic energy in addition to the energy from the invariant mass.
Using the data from the histograms of the and E of the muons, we can define the
4-momentum for the muons:
as well as Einstein's energy-momentum relation in natural units
Since the muon is much lighter than the at around 105 MeV (2), it is accelerated to high
enough speeds that its energy is dominated by the momentum. Thus the energy-momentum
relation for the muons simplifies to
Adding up the 4-momenta for the leading and sub-leading muons, we can solve the energy-
momentum relation for the mass of the , and we should see a spike around the invariant
mass. Here, this is done automatically using the TLorenzVector class,
which adds up the 4-momenta and calculates the mass.
Figure 9: Invariant mass of Z boson based on 4-momenta of of outgoing muons
Indeed, there is a very clear spike around GeV, which matches the value of the
of GeV used by the Particle Data Group quite well. (3)
Given the data set of around 10 000 events, we were relatively successful in measuring the
mass of the boson. This could obviously have been done more accurately using more
samples with more events, but the results were respectable given the sample we had. The
main challenge was the irrelevant muons which showed up in the plots, and while we
somewhat managed to filter them out, through only selecting the two muons with highest
, there were still a few that made it through. In order to improve the results we
could look at the truth information from a Monte-Carlo simulation, which would reveal how many
muons were actually in each event, as opposed to seeing how many tracks are reconstructed
by the simulated detector. Some of the false muons made it into the plot of the sub-leading muon .
This was probably because one of the relevant muons were lost outside the range of the detector, and one of
the false muons were detected instead, being labelled as sub-leading. Muons lost
outside the range is also presumed to be the cause of the events with only one or zero
muons. In order to try to completely eliminate the irrelevant muons, we might try to add a
threshold, so that muons with below a certain value, for example 10 GeV would be
ignored, before moving on to the rest of the filtering process. This would mean the total
number of events analyzed would be reduced, but it would also give more qualitative results.
We would also double check the eta-distribution by remaking the distribution from the pure
plus some samples to estimate the background from other physics sources. This way we would see if
the peaks are real and not just a red herring by virtue of using a pure sample.
(1) (Particle Data Group, Gauge and Higgs Bosons, 2020)
(2) (Particle Data Group, Muon, 2020)
(3) (Particle Data Group, Z boson, 2020)
MyxAODAnalysis.h (Used to declare the variables)
MyxAODAnalysis.cxx (Constructs and fills the tree with data)
ATestRunJobOptions.py (Inputs sample, executes MyxAODAnalysis.cxx with
the variables from MyxAODAnalysis.h, stores the tree in a root-file)
PlotTest.C (Takes in the tree and makes a histogram for each variable)