2. The ATLAS experiment and the LHC

Contents

1 Introduction . . . 6

2 The ATLAS experiment and the LHC . . . 7

2.1 The LHC . . . 7

2.2 The ATLAS detector . . . 7

2.2.1 Trigger . . . 8

2.2.2 Inner detector . . . 9

2.2.3 Calorimeter . . . 10

2.2.4 Muon spectrometer . . . 10

3 Theory . . . 11

3.1 The Higgs mechanism . . . 11

3.2 The Higgs boson in the MSSM . . . 11

3.3 Charged Higgs boson production and decay . . . 12

4 Software . . . 13

4.1 ATLAS software . . . 13

4.1.1 Athena . . . 13

4.1.2 Distributed analysis . . . 13

4.1.3 Datasets and data quality . . . 14

4.2 Algorithms . . . 14

4.2.1 Introduction . . . 14

4.2.2 Skimming algorithm . . . 15

4.2.3 Trigger algorithm . . . 16

4.2.4 Event cleaning algorithm . . . 16

4.2.5 Object selection algorithm . . . 16

4.2.6 Event selection algorithm . . . 17

4.2.7 Top quark reconstruction algorithm . . . 19

4.2.8 Source code and examples . . . 20

4.3 Scripts . . . 22

4.3.1 Scripts for statistics . . . 22

4.3.2 Scripts for histograms . . . 23

5 Preparatory analyses . . . 27

5.1 Monte Carlo analysis . . . 27

5.1.1 Datasets . . . 27

5.1.2 Object selection . . . 27

5.1.3 Event selection . . . 28

5.1.4 Results . . . 28

5.2 Analysis of 2009 data . . . 30

5.2.1 Datasets . . . 30

5.2.2 Object selection . . . 30

5.2.3 Event selection . . . 30

5.2.4 Results . . . 30

5.3 Analysis of early 2010 data . . . 30

5.3.1 Datasets . . . 31

5.3.2 Skimming . . . 31

5.3.3 Object selection . . . 31

5.3.4 Event selection and results for loose cuts . . . 32

5.3.5 Event selection and results for tightened cuts . . . 33

5.3.6 Event selection and results for dijet Monte Carlo . . . 34

5.3.7 Conclusions . . . 36

5.4 HSG5 acceptance challenge . . . 37

5.4.1 Datasets . . . 37

5.4.2 Object selection . . . 37

5.4.3 Event selection . . . 38

5.4.4 Results . . . 39

5.4.5 Acceptance challenge comparison . . . 40

5.4.6 Top quark search . . . 42

6 Analysis of 2010 data . . . 43

6.1 Datasets . . . 43

6.2 Object selection . . . 43

6.3 Systematic uncertainties . . . 44

6.4 Event selection . . . 44

6.5 Results . . . 44

6.6 Conclusions . . . 47

7 Summary and conclusions . . . 49

8 Acknowledgements . . . 51

A Job options, output, and histograms . . . 52

B Code listings . . . 60

B.1 Example PanDA configuration script . . . 60

B.2 Example stats configuration file . . . 60

B.3 Example histogram configuration file . . . 61

C Datasets, run numbers, and cross sections . . . 63

Bibliography . . . 70

List of Tables

4.1 Athena configuration parameters . . . 21

4.2 Dataset settings . . . 24

4.3 File settings . . . 25

4.4 Generic settings . . . 25

5.1 Monte Carlo cut flow statistics . . . 28

5.2 Loose cut flow statistics . . . 32

5.3 Tightened cut flow statistics . . . 34

5.4 Dijet cut flow statistics . . . 35

5.5 Acceptance challenge cut flow statistics . . . 41

5.6 Acceptance challenge comparison . . . 41

6.1 Top search cut flow statistics . . . 47

A.1 Job options for the skimming algorithm . . . 52

A.2 Printed output from the skimming algorithm . . . 52

A.3 Job options for the trigger algorithm . . . 52

A.4 Printed output from the trigger algorithm . . . 52

A.5 Job options for the event cleaning algorithm . . . 53

A.6 Printed output from the event cleaning algorithm . . . 53

A.7 Histograms from the event cleaning algorithm . . . 53

A.8 Job options for object selection algorithm . . . 53

A.9 Printed output from the object selection algorithm . . . 55

A.10 Histograms from the object selection algorithm . . . 55

A.11 Job options for event selection algorithm . . . 56

A.12 Printed output from the event selection algorithm . . . 57

A.13 Histograms from the event selection algorithm . . . 57

A.13 Histograms from the event selection algorithm (continued) . . . 58

A.14 Job options for reconstruction algorithm . . . 58

A.15 Printed output from the reconstruction algorithm . . . 59

A.16 Histograms from the reconstruction algorithm . . . 59

C.1 Datasets for Monte Carlo analysis . . . 63

C.2 Datasets for 900 GeV collision data . . . 63

C.2 Datasets for 900 GeV collision data (continued) . . . 64

C.3 Datasets for 900 GeV minimum bias Monte Carlo . . . 64

C.4 Datasets for 2010 Period B collision data . . . 65

C.5 Datasets for 7 TeV minimum bias Monte Carlo . . . 65

C.6 Datasets for 7 TeV dijet Monte Carlo . . . 65

C.7 HSG5 acceptance challenge datasets (2010 Period D3-6) . . . . 66

C.8 HSG5 acceptance challenge datasets (2010 Period E) . . . 66

C.9 HSG5 acceptance challenge datasets (2010 Period F) . . . 67

C.10 HSG5 acceptance challenge datasets (Monte Carlo) . . . 67

C.11 Top search datasets (2010 Period E-I) . . . 67

C.12 Top search datasets (Monte Carlo) . . . 69

List of Figures

2.1 The ATLAS detector . . . 8

5.1 Monte Carlo τ jet pT and ∆Φ . . . 29

5.2 Monte Carlo reconstructed W and top quark mass . . . 29

5.3 Monte Carlo χ²and reconstructed H⁺ m_T . . . 29

5.4 900 GeV τ jet p_Tand jet p_T . . . 31

5.5 Loose τ jet pTand jet pT . . . 33

5.6 Tightened τ jet pTand E_T^miss. . . 34

5.7 Tightened jet p_Tand reconstructed top quark mass . . . 35

5.8 Dijet τ jet pT and E_T^miss. . . 36

5.9 Dijet jet p_Tand top quark mass . . . 36

5.10 Acceptance challenge reconstructed top quark mass . . . 39

5.11 Acceptance challenge τ jet p_Tand E_T^miss . . . 40

5.12 Acceptance challenge jet pTand b jet pT . . . 40

6.1 Top search reconstructed top quark mass and pT . . . 45

6.2 Top search jet p_T . . . 45

6.3 Top search τ jet pTand η . . . 46

6.4 Top search E_T^miss and b jet p_T . . . 47

6.5 Top search cut flow . . . 48

1. Introduction

Particle physics aims at describing the world we live in at the subatomic scale.

Its arguable greatest success is the incorporation of all known fundamental particles and three out of four fundamental interactions in the Standard Model (SM). However, one hypothesized fundamental particle has evaded discovery since it was proposed in 1964: the Higgs boson [1].

Despite being searched for by the experiments both at the Large Electron- Positron Collider (LEP) at CERN and the Tevatron at Fermilab, it has ever eluded physicists. The motivations for constructing the Large Hadron Collider (LHC) at CERN were in part the confirming the predictions of the Standard Model, including the prospect of discovering or excluding the Higgs boson;

and in part by the prospect of finding new physics, in particular new particles in the Supersymmetry (SUSY) theory.

In the Minimal Supersymmetric Standard Model (MSSM) the Higgs boson of the SM is replaced by five different Higgs bosons. Two of these are the charged Higgs bosons, and their discovery is an active area of research at the ATLAS experiment.

Ever since computers first were incorporated into the field of particle physics, scientific computing has been an essential asset to manage and analyze the large amounts of data produced by experiments at particle colliders. The importance of computing at the experiments connected to the LHC cannot be overemphasized, and a considerable share of the projects resources and manpower have been dedicated to building software and data infrastructure.

In chapter 1 is given a brief overview of the ATLAS experiment and the LHC. Chapter 2 is a short description of the theory of the charged Higgs bosons. In chapter 3 is detailed analysis software developed by the author, towards searches for a charged Higgs boson in the final state of a τ lepton and quark jets. In chapter 4 several analyses on early collision data from the AT- LAS detector are described, and chapter 5 reports the result from an analysis of all data produced during 2010 towards searches for a charged Higgs boson.

2. The ATLAS experiment and the LHC

The main objective of the experiments at the Large Hadron Collider (LHC) is to answer the most prominent unresolved questions in particle physics, as well as further testing the parameters of the Standard Model (SM). The AT- LAS and CMS experiments are actively searching for the elusive Higgs boson predicted by the Standard Model. They are also searching for evidence of hy- pothesized supersymmetric particles. The LHCb experiment is investigating differences between matter and antimatter that can account for the apparent matter-antimatter imbalance in the Universe. The ALICE experiment attempts to create a quark-gluon plasma, a state similar to the conditions of the Universe just after the Big Bang, and to analyze its properties.

2.1 The LHC

The LHC spans the border between France and Switzerland near Geneva, and is operated by Conseil Européen pour la Recherche Nucléaire (CERN). It has a circumference of approximately 27 km, its nominal energy for protons is 7 TeV (center-of-mass energy√

s= 14 TeV), and it is designed for an instan- taneous luminosity of 10³⁴ cm⁻² s⁻¹[2]. Operating at design specifications, each beam consists of about 2800 bunches with a 25 ns spacing resulting in a bunch crossing frequency of 40 MHz.

The LHC started operating at 10 September 2008 [3]. On March 30 2010, the LHC started its research programme with the first proton-proton collisions at√

s= 7 TeV. Owing to its excellent performance, the long technical stop scheduled for 2012 to prepare the LHC for running at its full energy of√

s= 14 TeV has been postponed. With the hope of an early chance at finding new physics the LHC will continue its physics programme with proton-proton and lead ion collisions throughout 2011 and 2012.

2.2 The ATLAS detector

The ATLAS experiment is an international collaboration consisting of about 3000 scientists from 174 universities and institutes spread over 38 countries.

The ATLAS detector [4] is cylindrical in geometry with two end-caps to en-

sure full coverage in solid angle. The main constituents of the ATLAS detector are the inner detector, the calorimeter, and the muon spectrometer, which in turn are comprised of several sub-detectors. The constituents of the ATLAS detector are decribed in some detail below.

Figure 2.1:Schematic of the ATLAS detector

The operation of the detector is handled by the Trigger and Data Acquisi- tion (TDAQ) systems, and the Detector Control System (DCS). The Detec- tor Control System is responsible for powering and monitoring the detector.

The Trigger system handles filtering of the large amount of events read out from the detector. The Data Acquisition system is responsible for buffering and recording events, and also for controlling and monitoring the components involved in data-taking.

2.2.1 Trigger

The ATLAS trigger [4] system consists of three levels: L1, L2, and the Event Filter (EF). The L2 and EF triggers are collectively known as the High Level Trigger (HLT). At each level the interestingness of an event is is examined with an increased level of refinement and if necessary with more selection criteria than at the previous level. The L1 trigger is implemented using custom built electronics, while the HLT is almost completely based on commercially available computer and networking hardware. The implementation of the HLT enables incremental improvements to the trigger system without interfering with the detector.

At level 1 the unfiltered event rate of 40 MHz is reduced to about 75 kHz.

A decision to keep or discard an event is made based on a limited amount of the total detector information in less than 2.5 µs. The L1 trigger searches for muons, electrons, photons, and jets with high transverse momentum. Ad- ditionally it searches for large missing and total transverse energy. The L1 trigger uses specific trigger chambers to identify muons, and reduced infor- mation from the calorimeters to identify other objects. If an event passes the L1 trigger, it defines one or more Regions of Interest (RoI) subsequently used by the higher level triggers.

At level 2 the trigger system uses all the available data from the detector but in a region restricted by the RoI defined by the L1 trigger. The RoI accounts for approximately 2% of the event data. The L2 trigger is designed to reduce the event rate to below 3.5 kHz, with an average processing time of about 40 ms per event.

The event filter uses the ATLAS offline software (see Section 4.1) to fully reconstruct the events and then make its selection. The event filter also tags selected events based on which streams [5] the event belongs to. After the event filter the data rate is reduced to a maximum of 200 Hz, with an average event size of 1.3 Mbyte.

The trigger system is configured by trigger menus. Trigger menus are ta- bles specifying threshold values and selection criteria for the three trigger systems. Entries in the trigger menus are called trigger items and correspond to physics objects. The trigger items are identified by a notation composed of trigger level and one or more physics objects describing multiplicity, type, and E_T threshold value. For instance, the trigger EF_tau12_loose_xe20_noMu corresponds to an event containing a τ jet with E_T > 12 GeV, with loose identification criteria, a E_T^miss> 20 GeV, and does not contain a muon. Trig- ger items are hereafter called triggers.

2.2.2 Inner detector

The inner detector (ID) [4] is designed to provide pattern recognition, high momentum resolution, and measurements of both primary and secondary ver- tices for charged tracks. The ID is comprised of three complementary sub- detectors. High resolution pattern recognition is provided by the silicon pixel layers and the silicon microstrip (SCT) layers, which are located closest to the beam in the radial direction. The transition radiation tracker (TRT) located outside the pixel and SCT layers further improves pattern recognition and mo- mentum resolution, and in addition provides electron identification as a com- plement to the electromagnetic calorimeter. The ID covers a pseudorapidity range up to |η| < 2.5 for tracking and |η| < 2.0 for electron identification. To provide high resolution tracking of charged particles, the ID is immersed in a 2 T magnetic field.

2.2.3 Calorimeter

The calorimetry system [4] consists of electromagnetic and hadronic detectors divided into different systems based on location in pseudorapidity. The bar- rel calorimeters are located radially outwards from the beam. At the end-cap the electromagnetic end-cap calorimeter (EMEC) and the hadronic end-cap calorimeter (HEC) are located, and the forward calorimeter (FCal) is located closest to the beam. After having passed the tracking layers in the inner detec- tor, particles (except muons) deposit their energy in the calorimeters providing a measurement of the energy in the event. This information is required to suc- cessfully reconstruct the photons, electrons, and jets in the event, and also to provide a measurement of E_T^miss.

The EM barrel calorimeter covers the pseudorapidity range |η| < 1.475 and the EMEC cover the range 1.375 < |η| < 3.2; both providing full symmetry in the azimuthal direction φ . The high pseudorapidity range (3.1|η| < 4.9) is covered by FCal. The range |η| < 2.5 matches the range of the ID and is suited for high precision measurements of electrons and photons, while the rest of the calorimeter has sufficient precision to satisfy the requirements for jet reconstruction and E_T^missmeasurements. The EM calorimeters all use liquid argon (LAr) as their active medium.

The barrel and the extended barrel tile hadronic calorimeters cover pseudo- rapidity ranges |η| < 1.0 and 0.8 < |η| < 1.7 respectively. These calorimeters use scintillating tiles as the active medium. At the end-caps and in the forward region, covering the range 1.5 < |η| < 4.9, LAr calorimeters provide EM and hadronic calorimetry.

2.2.4 Muon spectrometer

The muon spectrometer [4] is located outside the calorimeter, and with its system of superconducting toroid magnets it forms the outer boundary of the detector. It is designed to detect charged particles that escape the calorimeter and to measure their momentum. Measurement of muons escaping the detec- tor is important both because they are a key element of interesting physics processes such as the dilepton decay of Z, and because it is required to have full information about the energy of an event.

3. Theory

3.1 The Higgs mechanism

The electroweak interaction unifies the two fundamental interactions electro- magnetism and the weak interaction. It is formulated as a SU (2) ×U (1) gauge theory with the massless gauge bosons W^±, W⁰, and B⁰. In the SM this sym- metry is spontaneously broken by the Higgs mechanism. The Higgs mecha- nism causes the W⁺ and W⁻ bosons to acquire mass and the W⁰ and B⁰ to coalesce into two different bosons: the massive Zand the massless photon.

The Higgs mechanism is described mathematically through the weak interac- tion by introducing a non-zero vacuum expectation value of the hypothesized self interacting Higgs field. In the electroweak interaction the Yukawa term in the Lagrangian is responsible for generating the masses of the fermions.

In the SM Higgs boson is a massive scalar (spin-0) boson. A comprehensive overview of the Higgs boson theory and the attempts that have been made to find it is given in Ref. [6].

3.2 The Higgs boson in the MSSM

One fundamental question of particle physics is the hierarchy problem, that is, why do the gauge couplings of the fundamental interactions differ so much.

One attempt to solve this problem involves introduction of Supersymmetry (SUSY). SUSY is a generalisation of the symmetries of quantum field theory which allows transformation from fermions into bosons and vice versa. The following description of SUSY and its relation to the Higgs boson is based on the review given in Ref. [6].

The Minimal Supersymmetric Standard Model (MSSM) is the minimal ex- tension to the SM where supersymmetry is realized. The MSSM includes the Type-II Two Higgs Doublet Model (2HDM) extension to the SM. The 2HDM predicts the existence of two Higgs doublets H_u and H_d. After elec- troweak symmetry breaking a spectrum of five Higgs bosons remain: one pair of charged Higgs bosons H^±, one CP-odd Higgs boson A⁰, and two CP-even Higgs bosons h⁰ and H⁰. In the supersymmetric structure of MSSM all pa- rameters of the Higgs sector is determined at tree level by two parameters:

the ratio of the H_u and H_d vacuum expectation values tanβ = v_u/v_d, and the mass of one Higgs boson. These formulas describe the relation between the different parameters:

m²_H±= m²_A+ m_W²

m²_H,h=1 2



m²_A+ m²_Z± q

(m²_A+ m²_Z)²− 4(m_Zm_Acos 2β )²



The masses of the charged Higgs bosons are restricted at tree level by m_H^± > m_W. Most of the Higgs sector parameter space is uncovered by ex- periment, except for extreme values of tan β which are either inaccessible by theory or excluded by prior experiments. In the remainder of this work, when describing processes involving H⁺ or H⁻its charge conjugate is implied.

3.3 Charged Higgs boson production and decay

The charged Higgs boson production and decay depends on the charged Higgs boson mass. In the mass range m_H^± < m_t the main production channel is qq, gg → t ¯t → ¯tbH¯ ⁺, while gb fusion (g¯b → ¯tH⁺) dominates above the top quark threshold [7].

Below the top quark threshold the H⁺ → τν decay is dominant, and for most values of tan β the branching ratio (BR) is almost 1. Decays to c ¯s and W hare also available, but at one or two orders of magnitude smaller in BR than to τν. For charged Higgs boson masses above the top quark mass the dominant decay mode is H⁺ → t ¯b. The H⁺→ τν channel is still available, and even though it has a lower BR it offers a signal that is less affected by the large backgrounds.

A comprehensive overview of the discovery potential of the charged Higgs boson at the ATLAS experiment is given in Ref. [8].

4. Software

Software is an important component of particle physics. The amount of data produced by the ATLAS experiment (and similar experiments) is too large to be handled by individual scientists. An infrastructure for recording, stor- ing, reprocessing, and analyzing data has been developed by the LHC and its experiments for this purpose.

In Section 4.1, the software frameworks used for the ATLAS detector and the Grid are described. Section 4.2 and Section 4.3 describe analysis algo- rithms and utility scripts developed by the author.

A comprehensive overview of the different software components used by ATLAS can be found in the ATLAS Computing: Technical Design Report [5].

4.1 ATLAS software

4.1.1 Athena

The Athena [5] framework provides users working with the ATLAS exper- iment with the necessary tools to perform physics data processing. Among many tasks it covers the generating, simulating, and digitizing of simulated events; as well as reconstruction and analysis of both collision data and simu- lated events.

Athena is built up by components offering flexibility to the user. Notable components include the application manager which controls the application, the data stores and converters which provide access to data, various tools and services to facilitate common tasks, and finally the algorithms and sequences which allow the user to run their programs.

4.1.2 Distributed analysis

The Grid is an infrastructure integrating computing and storage resources in data centres worldwide to provide a collaborative computing environment. To enable processing of the massive amounts of data coming out of the detectors connected at the LHC, computing and storage resources are provided by the worldwide LHC computing grid (WLCG). The WLCG is made up of four tiers each providing different services, from raw data processing at Tier 0 to the local Tier 3 sites.

Since the amount of data is so large, the philosophy when using the Grid for analysis is to run the programs where the data are located. Submitting programs to the Grid for data analysis is usually done with a user interface for distributed analysis. For Athena particularly two such interfaces are used:

Ganga [9] and PanDA [10]. Both systems have similar features for submitting, splitting, monitoring, and controlling jobs, as well as retrieving output. PanDA is more closely tailored to suit ATLAS analysis needs.

The DQ2 client tools are used to access and manage both input (collision data and from Monte Carlo) and output data from analyses and other tasks.

4.1.3 Datasets and data quality

Official ATLAS datasets for both collision data and Monte Carlo are cata- logued in the ATLAS metadata interface (AMI). AMI provides a searchable interface for datasets and keeps records of dataset properties.

Datasets come in a variety of different file formats, of which some are de- scribed below. The event summary data (ESD) format retains necessary infor- mation to re-run parts of the reconstruction. The Analysis Object Data (AOD) format contains reduced size output of physics quantities from the reconstruc- tion. AOD format datasets are smaller in size than ESD format datasets.

From ESD and AOD several Derived Physics Data (DPD) formats are cre- ated. The performance DPD formats Derived ESD (DESD) and Derived ESD Modified (DESDM) are useful for in-depth performance studies using specific samples. The physics DPD formats Derived AOD (DAOD) and Derived AOD Modified (DAODM) are further reduced in size and suitable for specific anal- yses. Secondary and tertiary DPD formats are commonly produced by ATLAS working groups for very specific analyses.

Data quality is a very important aspect of collision data coming from the ATLAS detector. The main user interface to data quality properties is the AT- LAS run query service. However, since this interface is very complex, a more common tool to use is the ATLAS good run list generator. A good run list provides a list of runs and luminosity blocks during which the beam condi- tions were stable and the detector functioned appropriately for data analysis.

In addition to the good run list generator it is common for ATLAS working groups to provide their own official good run lists.

4.2 Algorithms

4.2.1 Introduction

A set of algorithms suitable for charged Higgs boson searches in the τ+jets channel are developed by the author. As more data become available, the al- gorithms evolve with the evolution of data taking. Comparisons of collision

data and Monte Carlo in analyses towards H⁺searches become the focus to- wards the end of the project.

A number of philosophies are applied in the development of these algo- rithms. The algorithms shall interface with the core Athena tools and services directly, without making use of higher level utilities. The purpose of this phi- losophy is to gain an understanding of the Athena framework on the funda- mental level.

The job option files controlling the execution of the algorithms shall be kept as minimal as possible. The purpose of this philosophy is to have maximum control over what components are loaded with Athena.

The algorithms shall make good use of the C++ Standard Template Library (STL) [11] containers and algorithms. The purpose of this philosophy is to ensure code readability, to utilize the high optimization of STL algorithms, and to ascertain how well the Athena event containers conform to the STL specifications. Many of the Athena tutorials and examples available to a new user are written without explicit use of the STL, even though the StoreGate containers in Athena are tailored for this style of programming [5]. A plausible explanation is that the STL is a complex library that is hard to understand.

The algorithms shall make good use of templates, generic utility functions and functors. The purpose of this philosophy is to reduce code duplication, improve understandability by using descriptive names, and to improve read- ability by encapsulating verbose code snippets.

Each algorithm is configurable with a set of job options, and each produces output in the form of text and histograms. Job option and output specifica- tions can be found in Appendix A. In particular, for all algorithms except the skimming algorithm it is possible to specify a Monte Carlo truth container to account for Monte Carlo event weights.

4.2.2 Skimming algorithm

A skim is an event selection criterion on one or or a combined set of parame- ters of the objects in an event. Skims are applied to datasets to produce derived datasets of reduced size. The skimming algorithm is used when comparing re- sults from datasets with different skims, in order to get comparable numbers for the cuts in the event selection (see Section 4.2.6). The skimming algorithm is applied before any other algorithm.

The skimming algorithm defines two skims which are suitable for the DESD_MET data format. For an event to pass the skimming algorithm it must have either a E_T^miss or a reconstructed τ jet candidate with pT greater than the respective skim value.

4.2.3 Trigger algorithm

The trigger algorithm examines the active triggers for events and is used to reject those that do not fulfill basic requirements at an early stage. It is con- figured by specifying one or more required triggers in the job options file. To check if an event passes an individual trigger, Athena’s TrigDecisionTool is used. For an event to pass the trigger algorithm it has to pass all specified triggers. The algorithm has an option to change this requirement to accept an event if at least one trigger is passed. The ATLAS trigger system is detailed in Section 2.2.1.

4.2.4 Event cleaning algorithm

Event cleaning is used to reject events that are considered unfit for analysis and consists of two cleaning cuts. In the code the event cleaning algorithms is implemented in the Athena algorithm called ObjectCleaning.

Jet quality parameters are computed for all jets in the event with a p_Thigher than a specified threshold. The event is rejected if one or more jets do not fulfill the quality requirements. There are three quality classifications for jets [12].

Bad jets arise from various sources such spikes in the HEC, coherent electro- magnetic noise, LHC beam background, and cosmic ray showers. Two defini- tions for bad jets exist. Loose bad jets correspond to most of the problematic jets, while having an inefficiency of less than 0.1%. Tight bad jets have an in- efficiency not greater than a few percent, and should be used for analyses that need a very clean data sample. The event cleaning algorithm uses the loose bad jet definition, and from now on these are simply called bad jets. Ugly jets correspond to energy depositions in regions in the calorimeter where the mea- surement is not accurate, e.g. the transition between barrel and endcap, and regions where the calorimeter is not functioning according to specifications.

Jets that are neither bad nor ugly fulfill the jet quality requirements, and these are called good jets.

Events are also required to have at least one primary vertex with a specific number of tracks. If an event does not fulfill this requirement it is rejected.

4.2.5 Object selection algorithm

Object selection is used to select physics objects on which to perform analysis.

This selection is based upon cuts and requirements on parameters such as ob- ject pT and η; object identification algorithm and efficiency; object isolation;

and others. Exactly which parameters are used depends on the object and the analysis being performed. In the following the object selection is described for each individual analysis. An object which passes all parameters specified for its type is selected for further analysis.

An object might be reconstructed as more than one object type with vary- ing reconstruction quality. Two objects are considered to overlap if they are

both located within a cone of ∆R of a specified size. Overlapping objects are removed with priority reflecting their purity. If two objects overlap, the ob- ject with the lowest priority is removed. For instance, muons are identified with a high purity in the detector’s tracking facilities. Overlapping objects are selected in this order: muon, electron, τ jet, jet.

All objects that are selected are added to transient containers which are used in later stages of the analysis. The jet objects are also split into b jet and light jet containers based on the specified b-tagging algorithm [13] and weight.

4.2.6 Event selection algorithm

The event selection algorithm selects events for the reconstruction of the W and top quark candidates in the reconstruction algorithm (see Section 4.2.7). Cuts on different parameters are applied in sequence to select events that are interesting for the analysis, and to reject as much background as possible. The challenge of applying a good event selection is to enhance signal with respect to background for the analysis. It is often useful to sacrifice some signal events to reduce the background by a larger factor.

However, while removing background is important it is also important to maintain good statistics.

τ jet pT and E_T^miss

The cuts on τ jet p_Tand E_T^missare significant since the H⁺→ τν channel pro- duces either a hard τ jet and a neutrino or a hard neutrino. For the background these are generally much softer. The event is required to have exactly one τ jet with a p_Thigher than the τ jet p_Tcut value. The E_T^missof the event is required to be higher than the E_T^misscut value.

It is possible to configure the algorithm to instead allow one or more τ jets which pass the τ jet pTcut. This is useful to compensate for fake τ jets when using a loose requirement on the τ identification.

∆Φ

The τ and the neutrino emerging from the H⁺ decay can be hard without being boosted. If the H⁺ is not boosted the τ and the neutrino are close to back-to-back, resulting in a large angle ∆Φ between them. Requiring a large

∆Φ reduces much of the background without being detrimental to the signal.

∑ HTand E_T^misssignificance

∑ HT is defined by the sum of transverse momenta of all jets, τ jets, and E_T^miss in the event. The cut on ∑ HT is used to select events with a high amount of transverse momentum and it reduces much of the remove QCD backgrounds. The cut is applied by requiring that ∑ HT is higher than the cut value.

The E_T^miss significance is defined by E_T^miss/√

∑ ET, where ∑ ET is the sum of the transverse energies of all jets, τ jets, E_T^miss, and leptons. The E_T^misssig- nificance approximates the level of E_T^missin units of standard deviations of the background E_T^miss distribution, and it is large for events with decays such as H⁺→ τν compared to QCD multi-jet backgrounds [14]. The cut on E_T^misssig- nificance is used to suppress fake E_T^miss in QCD multi-jet and other back- ground events, and is particularly useful to counter the effects of pile-up. The cut is applied by requiring that the E_T^miss significance of the event is greater than the E_T^misssignificance cut value.

band light jets

The cuts on b and light jets are used to select events that contain enough con- stituents to reconstruct the objects in the final state: the W and the top quark.

These cuts can be configured for both H⁺ analysis and background estima- tion analysis. In the latter the main goal is to study possible backgrounds to H⁺→ τν, for example decays involving top quarks.

First a specific number of jets that all pass the jet pTcut value are required.

This includes both b and light jets. Of these jets one or more are required to be a b jet with a p_T greater than the b jet p_Tcut value. b jets are identified as described in Section 4.2.5.

It is possible to skip the b jet requirement and instead use an additional light jet in the top quark reconstruction (see Section 4.2.7). This setting is used to compensate for lack of calibration and optimization of the b-tagging algorithms in early data. It is also possible to specify whether the jets that pass the b tagging requirement, but not the b jet pTrequirement, should instead be considered as light jets.

Lepton veto

The H⁺→ τν decay does not produce additional leptons in the τ+jets chan- nel apart from the τ and the neutrino. Vetoing on events with additional hard leptons can be used to further suppress backgrounds. This cut is applied by requiring that the event has no electron or muon with a pT higher than the lepton veto value.

Trigger study

It is possible to configure the event selection algorithm to perform a trigger study by specifying a set of triggers. For each trigger the number of events that pass that trigger is printed. The trigger without a prescale that produces the highest efficiency would then be a good choice for the trigger algorithm in Section 4.2.3.

Application of cuts

At each specific cut, if an event does not pass no further cuts are applied and the event is rejected. For each cut histograms of the cut parameter both

before and after the cut are created. Histograms are also created for all cut parameters before and after all cuts. The textual output from the algorithm contains statistics on the number of events that pass each cut and are used to calculate cut efficiencies. The objects for the events that pass all cuts are stored in new transient containers which are subsequently used in the reconstruction algorithm below.

4.2.7 Top quark reconstruction algorithm

The reconstruction algorithm is used to reconstruct W and top quark candi- dates from the H⁺ decay, as well as computing the H⁺transverse mass.

First W candidates are reconstructed by combining unique pairs of light jets.

Then top quark candidates are reconstructed by combining all unique pairs of a W candidate and a b jet. This scheme reconstructs top quark candidates from the decay t → W b → jet − jet−b.

To select the best top quark candidate, one of two methods are employed depending on the type of analysis. For H⁺analysis the value of

χ²=(m_{j j}− m_W)²

σ (mW)² +(m_{b( j j)}r− mt)²

σ (mt)² (4.1)

is calculated for all top quark candidates and its constituent W candidate. The b j jcombination with the minimum value of χ² is selected as the best can- didate. m_W and m_t are the nominal W and t masses, and the reconstruction algorithm uses m_W = 80.4 GeV and m_t = 172.5 GeV. ( j j)^r denote the two jets used in the W reconstruction. σ (mW) and σ (mt) represent the resolution of the W and t mass reconstruction and are configurable.

A cut on χ²is applied to discriminate against backgrounds without hadron- ically decaying top quarks.

For background estimation analysis the b j j combination with the highest p_T is selected as the top quark candidate. The mass of the candidate m_{b j j}is required to lie within a mass window around m_t. The size of this mass window is configurable.

Histograms of the W reconstructed mass, the top quark reconstructed mass and pT, and χ² are plotted for all candidates. The same histograms are also plotted for all selected candidates as described above, as well as for the se- lected candidates that pass the χ² or mass window cut. For events that pass the χ²or mass window of cut the H⁺transverse mass mT is also plotted.

It is possible to skip the b jet requirement, and instead use an additional light jet for reconstruction. The W candidates are reconstructed using a combina- tion of two light jets, j j, above. The top quark candidates are reconstructed using three unique light jets, j j j, instead of b j j.

4.2.8 Source code and examples

Source code

The source code for the analysis program can be checked out, built, and run by following these instructions. The source code has been tested with Athena release 16.0.3. It is recommended that the user has some prior experience with compiling analysis programs, running Athena, and editing job options.

First create an Athena test area environment by following the instructions in the ATLAS computing workbook accessible via the CERN TWiki [15]. From the test area directory, the source code can be checked out with

$ cd $TestArea

$ svn co $SVNUSR/ohman/HSG5Analysis/tags/HSG5Analysis-01-00-01 HSG5Analysis

The program is built with

$ cd $TestArea/HSG5Analysis/cmt

$ cmt make

A job options file is required to run the analysis program. An example job options file is available via

$ cd $TestArea/HSG5Analysis/run

$ get_files.py -jo HSG5Analysis_topOptions.py

A suitable AOD or DESD dataset is required to run the analysis program.

The path to a dataset file is configured in the Globals.inputCollection variable in the job options file. Finally the analysis program is run through Athena with

$ cd $TestArea/HSG5Analysis/run

$ athena.py HSG5Analysis_topOption.py | tee athena.log

When the analysis is complete the output histograms will be available in the ROOT file HSG5Analysis.aan.root. General output and statistics from the analysis are available in the Athena log file athena.log.

Job options example

The HSG5Analysis_topOptions.py job options file is divided into several parts by annotation. The parts that are interesting to the user are the global and the algorithm settings.

The global settings is a class of convenience variables which may be dif- ferent for different datasets, even if the analysis settings for these datasets are identical. For example, the triggers setting is useful when the available trig- gers in collision data differ from those in the Monte Carlo samples one wants to compare with.

The global settings also contain variables that control whether the job should employ certain algorithms. For example, the value of useTrigger

controls whether the trigger tools and algorithm are loaded. This reduces Athena execution time if the trigger algorithm is not needed. The value of useGoodRunsList similarly controls whether a good run list should be used, and this is obviously only useful for collision data.

It is beneficial to split the job options into two files: analysis-specific and dataset-specific. For this reason some variables pertaining to the algorithm settings are defined in the global settings in order to be easily accessible. The value of the goodRunsList variable is used to define both the good run list file and name. For instance, by setting goodRunsList to ’MyGRL’, the job options will use MyGrl.xml in the current directory. The configurable param- eters of the global settings are listed in Table 4.1.

The algorithm settings part consists of job options for the individual algo- rithms and are generally identical when running the same analysis over differ- ent datasets. See Section 4.2 for documentation and Appendix A for reference.

Table 4.1: Global configuration parameters for the Athena job options example

Variable Description

audit Add the ChronoAuditor to the service man- ager.

useSkim Use the skimming algorithm.

useTrigger Use the trigger algorithm.

useEventCounters Use the event counter algorithm to count events between each algorithm.

useGoodRunsList Use the GRLTriggerSelectorAlg.

goodRunsList Base name of the good run list file.

isMCDataset Configure Athena for Monte Carlo.

eventWeightCollection Truth collection for event weights for Monte Carlo datasets.

triggers Triggers for the trigger algorithm.

inputCollection Input data files.

PanDA submission scripts

An example submission script for analysis using PanDA and pathena is in- cluded in the source code. The code listing is available in Appendix B, and it can be retrieved with

$ cd $TestArea/HSG5Analysis/run

$ get_files -jo RunPanda.py

$ get_files -jo HSG5Analysis_panda.py

The use_mc_dataset variable controls how the run_job() function is called. For Monte Carlo datasets the dataset name is given and for

collision data a good run list is supplied. Running on collision data also requires specifying a data type and stream. If none is given, AOD and physics_JetTauEtmiss are used respectively. To ensure uniqueness the script creates a unique sequential number to use in the output dataset name.

Before submitting a run to PanDA, its environment must be properly set up by following the instructions on the CERN TWiki [15].

4.3 Scripts

A set of scripts are used to extract information and statistics from the Athena log files and to generate ROOT scripts to manipulate and display histograms.

Each script is implemented to perform one specific task, and are designed as easily replaceable building blocks. The scripts can be checked out with

$ svn co $SVNUSR/ohman/HSG5Scripts/tags/HSG5Scripts-01-00-01 HSG5Scripts

4.3.1 Scripts for statistics

4.3.1.1 process-output.sh

process-output.sh takes output dataset directories from PanDA and ex- tracts the log file archives for each subjob. It then parses the Athena log file for each subjob, extracting the printed output of the analysis algorithms. The different outputs that are extracted are listed in Appendix A. The results are stored in stdout_processed.txt in each subjob directory. These files are subsequently used to create the Python pickle files in Section 4.3.1.2.

process-output.sh output-dataset[ output-dataset[...]]

4.3.1.2 create-pickles.py

create-pickles.py parses processed output files and collects information and statistics into four Python pickle files. These files are used by the scripts in Section 4.3.1.3 and Section 4.3.1.4.

create-pickles.py output-dataset[ output-dataset[...]]

4.3.1.3 print-stats.py

print-stats.py prints job and dataset information; algorithm settings; trig- ger statistics; statistics for event cleaning object selection, event selection, and reconstruction; trigger and skim efficiencies; and cut flow statistics. This script can operate either directly on an output dataset directory or on a configuration file. The configuration file is described in Section 4.3.1.5.

print-stats.py [options] {dir|configuration file}

4.3.1.4 compare-stats.py

compare-stats.py prints job and dataset information and compares statis- tics between two or more output datasets. This script is mainly used to com- pare statistics between equivalent jobs on collision data and Monte Carlo, but can also be used to compare the results of using different cuts, etc. The compare-stats.py script requires a configuration file specifying two or more datasets. The configuration file is described in Section 4.3.1.5.

compare-stats.py [options] {configuration file}

4.3.1.5 Statistics configuration file

By using a configuration file, it is possible to combine the output of several datasets into one. This is necessary when displaying the combined output from several jobs, e.g. when using multiple background datasets or multi- ple collision data runs. The configuration file consists of two Python dictio- naries, names and datasets, that each have a left and a right key. The names dictionary defines display names for the combined datasets listed in the datasets dictionary. The datasets lists dataset titles, scales, and dataset paths for each individual output dataset in the combined datasets. An example configuration file is listed in Section B.2.

4.3.2 Scripts for histograms

4.3.2.1 create-root.py

create-root.py generates ROOT scripts according to the specification in the configuration file as described in Section 4.3.2.2. It uses merged ROOT files from one or more output datasets prepared according to Section 4.3.2.3, and a provided histogram database which is described in Section 4.3.2.4. The output are generated ROOT scripts used to display and save images of one or more histograms, and these are detailed in Section 4.3.2.5.

create-root.py [options] {configuration file}

4.3.2.2 Histogram configuration file

The configuration file consists of a Python dictionary specifying which output datasets to use when displaying plots of histograms, which ROOT scripts to generate, and a number of generic settings. An example histogram configura- tion file is listed in Section B.3.

Each entry in the datasets dictionary consists of the settings listed in Table 4.2. The dataset setting specifies the path to the output dataset directory. This directory should contain the Python pickle files created by create-pickles.py (see Section 4.3.1.2) and the merged ROOT file (see Section 4.3.2.3).

The value of the scale setting is used when rescaling histograms, for instance when rescaling Monte Carlo histograms to the luminosity of data.

Lastly the hist_title setting declares the name of the dataset as displayed in the histogram legend, and the attributes settings specifies plotting at- tributes.

Table 4.2: Dataset settings

Setting Type Description

hist_title string Title of the histogram in the legend.

scale float Value used to rescale histograms from this dataset.

dataset string Path to the output dataset directory.

attributes dict Plotting attributes for histograms from this dataset.

use_marker int Use markers when drawing the histogram.

marker_color string Draw markers using this colour.

marker_style int Draw markers using this style.

use_line int Use lines when drawing the histogram.

line_color string Draw lines using this colour.

line_style int Draw lines using this style.

use_fill int Use fill when drawing the histogram.

fill_color string Draw fill using this colour.

fill_style int Draw fill using this style.

stack bool Stack the histogram with other histograms that have the stack setting. Histograms are plotted stacked by default.

Each entry in the files dictionary corresponds to a generated root file. The available settings are listed in Table 4.3. The name setting specifies the name of the generated file for this entry. The db setting specifies which histogram database entry to use, i.e. which histograms to plot when executing the gener- ated file in ROOT. The header setting specifies the legend header and can be used to give a name to the plot.

Finally the normalization setting specifies how the histograms should be rescaled. If set to ’none’ the histograms are left as-is, while a value of

’unity’ causes the histograms to be rescaled to unity. To scale Monte Carlo histograms to the luminosity of data the value ’norm’ should be used for this setting, and the scale factors for the relevant output datasets should be specified in the corresponding dataset entry as described above.

The generic settings are listed in Table 4.4. The save_img setting specifies if the displayed plots should be saved as GIF, PNG, and PDF files. The y_

axis_title setting specifies the title of the Y-axis in all plots. If a generic setting has a counterpart either in the datasets entries or in the files entries it is overridden.

Table 4.3: File settings

Setting Type Description

name string File name of the generated ROOT script[1].

db string Entry in the histogram database.

header string Legend header.

normalization string Scaling for the dataset.

y_axis_title string Title for the Y axis.

x_axis_title string Title for the X axis.

y_axis, x_axis dict Settings for the X and Y axis scales.

log_scale int Use logarithmic scale.

min float Minimum value for the axis scale.

max float Maximum value for the axis scale.

legend_geometry list Legend placement[2].

[1].C will be appended automatically. [2]Relative to the bottom left corner of the plot on the format [x-low, y-low, x-high, y-high].

Table 4.4: Generic settings

Setting Type Description

save_img bool Save images (GIF, PNG, PDF).

y_axis_title string Title for the Y axis.

legend_geometry list Legend placement[1].

[1]Relative to the bottom left corner of the plot on the format [x-low, y-low, x-high, y-high].

4.3.2.3 Histogram preparation

To use the create-root.py script, the output datasets must be properly pre- pared. The output ROOT files from each subjob must be merged into a ROOT file named merge.aan.root in the directories specified in the datasets en- tries (see Section 4.3.2.2). If multiple output datasets are used to create one histogram, the merged ROOT files from all datasets must in turn be merged.

Merging is done with the hadd program (shipped with ROOT).

4.3.2.4 Histogram database

The histogram database is a Python file containing a dictionary with named entries describing which histograms to plot. Some entries are used to plot a single histogram while others are used to plot two or more histograms in the same ROOT window. The histogram database can be found in histogram_

db.py located in the script directory.

4.3.2.5 Using the generated ROOT scripts

The generated ROOT scripts are located in the root/ directory under the current directory, unless the -o option to create-root.py is used. When executing a generated ROOT script, a ROOT window containing one or more plots will be displayed. If the save_img setting (see Section 4.3.2.2) is used GIF, PNG, and PDF files of the plots will be saved to the img/ directory.

The generated ROOT scripts can be executed by

root <root-script>.C

5. Preparatory analyses

5.1 Monte Carlo analysis

t ¯tis the largest contribution to the background to H⁺ → τν searches. Dis- tributions of simulated H⁺ and t ¯t datasets are compared. In this analysis the objective is to identify good selection cuts for H⁺ analysis on collision data, and to ascertain that the largest contribution to the background is sufficiently suppressed.

5.1.1 Datasets

A Monte Carlo dataset for H⁺→ τν with a 130 GeV H⁺mass generated with PYTHIA [16] is used for the signal, and a Monte Carlo dataset for t ¯t decays generated with MC@NLO/JIMMY [17, 18] is used for the background. The datasets and the expected number of events for 1 fb⁻¹in the m^max_H scenario [19]

are listed in Table C.1.

5.1.2 Object selection

As a baseline, all reconstructed objects (muons, electrons, τ jets, and jets) are required to have pT> 10 GeV to avoid the problematic low-p_T region.

Muons are reconstructed from trajectories in the muon spectrometer using the Staco algorithm [13] and are required to have a purity of about 99%. Elec- trons are reconstructed by matching a track in the inner detector with energy depositions in the electromagnetic calorimeter using the medium quality re- quirements [20].

For the reconstruction of τ jets seeds from a fixed cone jet finder starting from topological clusters [21] are used. Further, tight quality requirements on the τ log-likelihood identification [22] is required. Jets are reconstructed with the same fixed cone jet finder and a size parameter of R = 0.4, but starting from calorimeter tower signals. These jets are calibrated using global cell reweight- ing (GCW) [23]. b jets are identified using a combination of secondary vertex and 3D impact parameter tagging algorithms.

E_T^miss is computed from calorimetry and momentum of tracks identified as muons, where the different calorimeter cells are calibrated differently depend- ing on which type of object they belong to according to the "refined final"

scheme, and calibrated using local hadronic calibration [24]. Finally objects

overlapping within a cone of ∆R < 4.0 are removed according to the priority defined in Section 4.2.5.

5.1.3 Event selection

C1) Trigger EF_xe20 and EF_tau16_loose C2) Exactly one τ jet with p_T> 50 GeV C3) E_T^miss> 80 GeV

C4) ∆Φ > 0.7

C5) At least 3 jets with p_T> 15 GeV

C6) At least one jet tagged with IP3D + SV1 > 3.0 and pT> 30 GeV C7) Veto on leptons with p_T> 10 GeV

C8) χ²< 5.0

5.1.4 Results

The cut flow statistics in Table 5.1 display efficient reduction of the t ¯t back- ground to an order of magnitude less than for the H⁺signal. The most effec- tive cuts in increasing the signal-to-background ratio are the cuts on τ jet p_T,

∆Φ , and the lepton veto.

The distributions of τ jet p_Tand ∆Φ before cut C1 and C4 respectively, are shown in Figure 5.1. The distributions of the W and top quark reconstructed mass are shown in Figure 5.2, displaying peaks around the nominal masses.

Finally, the χ²distribution before cut C8 and the reconstructed H⁺m_Tfor the events that pass cut C8 are displayed in Figure 5.3.

Table 5.1: Cut flow statistics for H⁺→ τν versus t ¯t Monte Carlo.

H⁺→ τν (Signal) t ¯t(Background)

Efficiency Efficiency

Cut Events Rel. [%] Acc. [%] Events Rel. [%] Acc. [%]

41000 100.0 100.0 160900 100.0 100.0

C1) 22264 54.30 54.30 82580 51.32 51.32

C2) 3231 14.51 7.880 3144 3.808 1.954

C3) 1036 32.06 2.526 989 31.45 0.6145

C4) 735 70.94 1.792 540 54.64 0.3358

C5) 599 81.51 1.461 452 83.61 0.2807

C6) 303 50.60 0.7391 245 54.19 0.1521

C7) 197 65.14 0.4815 111 45.39 0.0691

C8) 115 58.44 0.2814 56 50.72 0.0350

[GeV]

τ

pT

0 50 100 150 200 250

-1events / 1 fb

1 10 102

103

104

105

130 GeV H+

MC t t

0 50 100 150 200 250

1 10 102

103

104

105

(a) τ jet pTdistribution

φ

∆

0 0.5 1 1.5 2 2.5 3

-1events / 1 fb

10 102

103

130 GeV H+

MC t t

0 0.5 1 1.5 2 2.5 3

10 102

103

(b) ∆Φ distribution

Figure 5.1: Distributions of τ jet pTbefore cut C2 (a) and ∆Φ before cut C4 (b) for H⁺versus t ¯t Monte Carlo. Histograms scaled to 1 fb⁻¹.

[GeV]

mjj

0 20 40 60 80 100 120 140

-1events / 1 fb

0 20 40 60 80 100 120

130 GeV H+

MC t t

0 20 40 60 80 100 120 140

0 20 40 60 80 100 120

(a) Wmass distribution

[GeV]

mbjj

0 50 100 150 200 250 300

-1events / 1 fb

0 20 40 60 80 100 120

130 GeV H+

MC t t

0 50 100 150 200 250 300

0 20 40 60 80 100 120

(b)Top quark mass distribution

Figure 5.2: Distributions of reconstructed W mass (a) and reconstructed top quark mass (b) for H⁺versus t ¯t Monte Carlo. Histograms scaled to 1 fb⁻¹.

2 min χ

0 5 10 15 20 25 30 35 40 45 50

-1events / 1 fb

1 10 102

103

130 GeV H+

MC t t

0 5 10 15 20 25 30 35 40 45 50

1 10 102

103

(a) χ²distribution

[GeV]

mT 80 100 120 140 160 180 200 220 240 260 -1events / 1 fb

0 10 20 30 40 50 60

130 GeV H+

MC t t

80 100 120 140 160 180 200 220 240 260 0

10 20 30 40 50 60

(b) H⁺mTdistribution

Figure 5.3: Distributions of χ²before cut C8 (a) and reconstructed H⁺m_T(b) for H⁺versus t ¯t Monte Carlo. Histograms scaled to 1 fb⁻¹.

5.2 Analysis of 2009 data

2009 collision data are compared with minimum bias Monte Carlo. At this very early stage of data taking there are still a lot of uncertainties in collider and detector performance. The objective of the comparison is to find whether analyses on collision data yield the expected results.

5.2.1 Datasets

Data from 2009 900 GeV collisions with a good run list for the February 2010 reprocessing of the 2009 collision data is used to select run numbers and luminosity blocks. The datasets and run numbers are listed in Table C.2.

For Monte Carlo a minimum bias sample generated with PYTHIA is used.

The dataset and theoretical cross section is listed in Table C.3.

5.2.2 Object selection

The same object selection settings as in Section 5.1 are used with the follow- ing modifications: τ jets are identified using simple cuts with loose quality requirements [22]. Electrons are identified from calorimetry only as per the loose identification requirements [20].

5.2.3 Event selection

C0) Good run list

C1) At least one τ jet with p_T> 15 GeV C2) At least 3 jets with pT> 10 GeV

5.2.4 Results

The distribution of τ jet pT before cut C1 and jet pT before cut C2 are dis- played in figure 5.4. The shape of the τ jet pT distribution agrees decently with Monte Carlo. For jet pTdistribution the statistics is low.

5.3 Analysis of early 2010 data

2010 collision data are compared with minimum bias and dijet Monte Carlo.

Two different sets of cuts (loose and tightened) are applied to provide different levels of statistics in the comparison. The objective is to further investigate how well the results from analysing collision data matches expectations from Monte Carlo.

[GeV]

τ

pT

0 50 100 150 200 250

Arbitrary units

10-3

10-2

10-1

1 10 102

Minbias MC Data 2009

0 50 100 150 200 250

10-3

10-2

10-1

1 10 102

(a) τ jet pTdistribution

[GeV]

jet

pT

0 50 100 150 200 250

Arbitrary units

10-3

10-2

10-1

1 10 102

Minbias MC Data 2009

0 50 100 150 200 250

10-3

10-2

10-1

1 10 102

(b)Jet pTdistribution

Figure 5.4: Distributions of jet p_Tbefore cut C1 (a) and jet p_Tbefore cut C2 (b) for 2009 data versus minimum bias Monte Carlo. Histograms scaled to unity.

5.3.1 Datasets

Data from 2010 Period B 7 TeV collisions with a good run list for the May 2010 reprocessing of the 2010 collision data is used to select run numbers and luminosity blocks. The integrated luminosity corresponds to 8.8 ± 0.97 nb⁻¹[25]. DESD_MET performance DPD datasets with skims on τ jet pT and E_T^miss are used, with the datasets and run numbers are listed in Table C.4.

For Monte Carlo a minimum bias sample generated with PYTHIA is used for two analyses, and five dijet samples also generated with PYTHIA are used for the third analysis. The different dijet samples represent different minimum and maximum p_T of the jets (partons) produced in the events, where higher values will have a smaller theoretical cross section. The minimum and max- imum jet pTvalues are input parameters to the PYTHIA generator [16]. The minimum bias and dijet datasets and their theoretical cross sections are listed in Table C.5 and Table C.6.

5.3.2 Skimming

The skimming algorithm (see Section 4.2.2) is employed for the minimum bias and dijet Monte Carlo datasets to obtain an initial event selection which is representative for the DESD_MET datasets. Events that do not contain a τ jet candidate with pT> 15 GeV or E_T^miss> 15 GeV are rejected.

5.3.3 Object selection

The same object selection settings as in Section 5.1 are used with the follow- ing modifications: τ jets are identified using simple cuts with loose quality requirements [22]. Electrons are identified from calorimetry only as per the loose identification requirements [20]. For jet reconstruction the anti-k(t) re-