Implementing a physics analysis such as those on-going at the Large Hadron Collider at CERN necessitates to get some knowledge on what is reconstructed in a detector. The reconstruction of a collision then leads to a small set of physics objects that any single analysis of LHC collision data will (deeply) investigate.
[image credits: CERN]
As a first step to this project aiming to offer to Utopian contributors a way to help particle physics research, I decided to start with the description of three of those objects.
In parallel, I have detailed the computer framework which this project is relying on and how these objects are embedded into it.
In this post, I focus on a fourth class of objects that are called jets, and I introduce some of the properties of the objects that are used in the design of an analysis.
As usual, an exercise is proposed at the end of the post in order to get used to the concepts.
This project targets the design of a set of independent C++ codes reproducing existing physics analyses performed at the CERN Large Hadron Collider (aka the LHC). Those pieces of codes are planned to be merged to the MadAnalysis 5 Public Analysis Database that is used by particle physicists for research.
The MadAnalysis 5 framework can be downloaded from LaunchPad (a competitor to GitHub sharing the same key principles) or from its GitHub mirror. External dependencies have then to be installed according to these installation instructions.
[image credits: Harp (CC BY-SA 3.0)]
Stable particles correspond to objects that are stable enough to reach the detector undisturbed, and therefore interact with it.
As I have explained in my previous post, these objects can directly be used in the MadAnalysis 5 framework.
event.rec()->electrons() container.event.rec()->muons() container.event.rec()->photons() container.I now move on with the next class of physics objects that are reconstructed in a detector and that one needs in a physics analysis, and I will then start discussing the properties of all objects that are used in the design of realistic LHC search.
Although the LHC collides protons, protons are not elementary. In a high-energy proton-proton collision, we have in fact a collision between two of the proton constituents (as largely detailed here).
Those constituents consist in strongly-interacting elementary particles named quarks and gluons. However, more quarks and gluons will be produced by radiation originating from the colliding guys, on top of those that could be parts of the collision products.
[image credits: ATLAS@CERN]
Once produced, very highly-energetic strongly-interacting particles radiate other highly-energetic particles, which radiate themselves, and so on.
At each radiation, the energy decreases as the energy of the mother particle is shared among the daughter particles.
When the energy becomes too small, the radiation phenomenon stops.
At the end of the day, we get thus a collection of not too energetic particles roughly moving along the direction of the original quark or gluon.
By virtue of the theory of the strong interactions, none of these radiated quarks and gluons can be observed. They will instead form composite states as a result of what is called confinement.
All those composite states, that are the guys that will interact with the detector material, are again moving along the same direction, and are therefore organized in what we actually call a jet of strongly-interacting particles that can be reconstructed in the detector.
[image credits: CMS@CERN]
Jets are thus crucial and of course available within the MadAnalysis 5 framework.
In order to access their C++ container, one makes use of the event.rec()->jets() object, similarly to what we had done here for electrons, muons and photons.
This event.rec()->jets() guy is hence a vector whose elements are all C++ representations of jets.
There are generally many jets in the results of an LHC collision (easily several dozens), and not all jets are interesting. We therefore want to determine the set of relevant jets on the basis of the properties of these jets.
To this aim, we generally use a small number of jet properties. Because of the remnants of the colliding protons lying along the collision axis, there is no way to get a clean vision of what is going on in this direction. We consequently focus on the plane that is transverse to the collision axis.
Let us assume that we have a RecJetFormat object named myjet (event.rec()->jets() is hence a collection of RecJetFormat objects). The most important properties are:
myjet.et(),myjet.pt(),myjet.eta().The momentum describes more or less how the particle moves, and the transverse momentum restricts the motion to what is going on in the transverse plane. The pseudorapidity is a very useful variable describing the angle of the particle track with respect to the collision axis.
Particles are identified (i.e. tagged as an electron, a jet, etc.) according to their fingerprints in a detector. These fingerprints may be very similar in some cases, so that it may occur that a given object could be equally tagged as two different objects.
[image credits: ALICE@CERN]
For instance, an electron could be sometimes seen as a jet. There is a non-zero mistag probability.
A given physics object is thus often included in several collections, and the overlap has to be removed at the level lof the analysis.
Let us take for example an electron myelectron and a jet myjet that are the same object. We do not know at this stage whether this object has to be considered as a jet or an electron.
The analyses implement some criteria that allow us to make such a decision.
For instance, if the angular distance (between the jet and the electron is smaller than some threshold, one should remove the object from the jet collection and consider that it is an electron.
To effectively remove this overlap in the C++ code, the only thing we need to know is how to evaluate the angular distance between the myelectron and myjet quantities. This is done through myjet.dr(myelectron), which directly returns this angular distance.
Other properties are important, but this will be treated in the next posts. For now, I only add that all the above properties are also available for electrons and muons (stored as instances of the RecLeptonFormat class) and photons (stored as instances of the RecPhotonFormat class).
For this exercise, we will investigate an existing search for supersymmetry undertaken by the ATLAS collaboration. The corresponding research paper can be obtained here.
Please do not try to understand every single line of that study, and go instead directly to section 5 (pages 12-14). The idea is to implement the object definition described in this search as close as possible. Golden rule: everything from the paper that sounds weird and that I have not mentioned so far can be ignored. Any question can of course be asked in the comments. Always! ;)
The third paragraph of the section details how baseline electrons are defined. Create a vector with the electrons matching the momentum and pseudorapidity requirements that are mentioned in this paragraph. Ignore electron isolation.
The fourth paragraph of the section defines baseline muons. Create a vector with the muons matching the momentum and pseudorapidity requirements that are mentioned in this paragraph. Once again, isolation can be ignored.
The last paragraph of page 13 defines baseline jets. Ignore the pile-up and jet cleaning stuff and create a vector of baseline jets.
Go directly to the third paragraph of page 14 and implement the overlap removal procedure between baseline jets, muons and electrons. Ignore the b-tags, ghosts and shared track stuff. In short, the second and fourth removals shown in Table 3 on page 15 must be implemented.
Create vectors with signal electrons, muons and jets, to be extracted from the corresponding vector of baseline objects (see the fifth and sixth paragraph of the section).
Print the number of baseline electrons, muons and jets before and after the removal procedure. Print the number of signal electrons, muons and jets.
Apply the code on the previous sample of 10 simulated LHC collisions (see here).
Don’t hesitate to write a post presenting and detailing your code allowing to get to the answer. Please do not forget to mention me directly within your post, so that I could easily find it and to commi your code on this GitHub repository.
The deadline is Sunday June 10th, 16:00 UTC.
SteemSTEM is a community-driven project that now runs on Steem for more than 1.5 year. We seek to build a community of science lovers and to make the Steem blockchain a better place for Science Technology Engineering and Mathematics (STEM).
More information can be found on the 