Measuring Properties of W and Z Bosons with Dø Data

MEASURING PROPERTIES OF W AND Z BOSONS WITH DØ DATA

Third Year Laboratory

Contributions from Nasim Fatemi-Ghomi, Gavin Hesketh, Peter Walker, Mark Owen, Stefan Söldner-Rembold and David Bailey.

MEASURING PROPERTIES OF W AND Z BOSONS WITH DØ DATA

Third Year Laboratory

AIMS 1. To understand the data analysis techniques used in modern particle physics experiments. 2. To use real and simulated data to understand the properties of elec- troweak gauge bosons. 3. To understand the principles of a particle physics detector.

OBJECTIVES 1. To write a C++ program to select W and Z events using simulated and real data. 2. To use the data to measure the mass of the W and Z bosons. 3. To use the data to measure the ratio of the W and Z production cross sections and determine the branching ratio BR 푊 ⟶ 휇휐 .

1 27/08/2009

INTRODUCTION DØ is a particle detector at the Tevatron collider at Fermilab near Chicago. The Tevatron collides protons with anti-protons at energies of up to 980 GeV each, giving a collision energy in the centre-of-mass system of 1.96 TeV. The overall aim of the experiment is to test the Standard Model of particle physics and to search for new phenomena – specifically to measure the mass (and other properties) of the top quark and W boson and to search for the Higgs boson.

The processes being observed are rare, so statistical analysis is used to sieve information from large quantities of data. During a data-taking period (called a „run‟), millions of interactions (called „events‟) happen every second. Each event produces many kilobytes of information. Ideally we would store all the events for later analysis, but there is simply not enough bandwidth available to record all this information, and a significant amount of it is really of little use. Consequently, “smart” hardware and software triggers are used to make quick decisions about which events should be looked at more closely. These triggers filter out the interesting events, reducing the rate from millions per second to a few hundred per second. This rate is manageable, but still generates many gigabytes of data which require large computing resources to analyse.

You have been given a subset of this large dataset which has been preselected (i.e. filtered) to contain at least one muon in every event.

CARRIERS OF THE WEAK FORCE: THE W AND Z BOS- ONS Like the other fundamental forces (the strong and electromagnetic interactions), the weak interaction is also carried by the exchange of elementary, spin-1 bosons which act as the force carriers between quarks and/or leptons. There are three such bosons – the charged W+ and W- and the neutral Z boson. In contrast to the massless photon of electromagnetism, the weak bos- 2 2 ons have masses of 푀푊 = 80.3 GeV/푐 and 푀푍 = 91.2 GeV/푐 .

The W bosons decay into two quarks or into a charged lepton and its corre- sponding neutrino. The Z boson decays into pairs of quarks or leptons of the same flavour. In this experiment you will study the decays of W bosons into a muon and muon-neutrino and the Z boson decays into a pair of muons (휇+휇−).

2 27/08/2009

The branching ratios (i.e. the fraction of all decays of the W/Z that go to this final state) are predicted by the Standard Model. A good introduction can be found in “Particle Physics”, B.R. Martin and G. Shaw, Wiley, Chapter 8.

The goal of this analysis is to determine the branching ratio (BR) of W bosons into muons – i.e. the fraction of W bosons decaying into a muon and neutrino. This branching ratio can be calculated in the Standard Model (SM) using other SM parameters as input. Conversely, by measuring SM parameters such as BR 푊 ⟶ 휇휐 or the Z mass, we can constrain as yet unmeasured parameters such as the Higgs mass (assuming the SM is correct).

THE DØ DETECTOR AND DATA For an introduction to the DØ detector you can look at http://www- d0.fnal.gov/public/index.html and also read chapter 3 of the MSc thesis by N. Fatemi-Ghomi. A schematic view of the detector is show in Figure 1. You should make sure you understand how muons are identified in the DØ detector before starting your data analysis.

Figure 1: Schematic view of the DØ experiment.

For this experiment a small subset of the data has been prepared containing events with at least one muon with a momentum component transverse to

3 27/08/2009 the beam (transverse momentum) of more than 15 GeV/푐. The data file, expt.root, contains approximately three million events. It is a slightly sim- plified version of the actual data format used in the experiment. The attrib- utes of the event are stored in a tree-like structure called a „tuple‟. There are four „branches‟: EVT, MET, MU and TRIG. Each branch contains information derived from a different subsystem. Refer to the appendix for details of what each branch contains.

To perform the analysis you will need to run over two sets of data. One taken from the experiment and one generated from a Monte Carlo simulation. The Monte Carlo program generates physics processes – in our case the production of W and Z bosons and their decay into muons. It then takes all the particles produced and tracks them through a full simulation of the detector, producing a data structure equivalent to the experimental data. The Monte Carlo data is then reconstructed by the same programs as real data. The simulated events consist purely of the processes you are looking for, without any background, whereas the real experimental data is a mix of both processes and backgrounds that need to be removed. The experimental data were taken in 2003 over a period of about six months.

ANALYSIS As a general rule, always make histograms of the variables you are studying. Especially important are the variables that you use to make event selections with. You should make histograms of these variables before you make a selection so that you can justify your choice later. It‟s also a good idea to either save these histograms in a file or print them to refer to later. When you make histograms, it is always useful to compare real and Monte Carlo (MC) data.

Reconstructing and Selecting Z Events In events with two muons, calculate the invariant mass of the two muons. Compare the variables you find in the tuple for the simulated and real Z events and try to find a suitable selection to reduce the background. By plot- ting the invariant mass distribution for selected and rejected events sepa- rately you can study whether your selection rejects mainly background or signal (i.e. real Z events you want to keep).

Some questions:

 What kind of background events are in the data sample?

4 27/08/2009

 Why are the Monte Carlo and data invariant mass distributions different?  What is the origin of events where both muons have the same charge?  Why are there no events with mass less than 30 GeV/푐2?  Which background is rejected by the isolation variables?  Do we need to know the muon mass to reconstruct Z events?

Cosmics Identify the cosmic events in the data sample using the timing information and the angular separation Δ휃 and Δ휙 between the muons and plot a two- dimensional histogram of 휙 and the pseudorapidity 휂.

Some questions:

 What is the origin of the cosmic ray background in DØ?  What scintillator times do you expect for cosmic muons?  What is the origin of the structure in the 휂, 휙 histogram?

Z Mass Once you have selected a clean sample of Z events, determine the Z mass by fitting a suitable function to the mass histogram.

 What defines the width of the Z peak?

Reconstructing and Selecting W Events Define a selection for W events and reconstruct the transverse mass, defined as: 2 2 2 푀푇 = 퐸/ 푇 + 푝푇 − 퐸/푥 + 푝푥 − 퐸/푦 + 푝푦 where 푝푥 and 푝푦 are the 푥 and 푦 components of the muon momentum and 퐸/푥 and 퐸/푦 are the 푥 and 푦 components of the missing transverse energy 퐸/ 푇. Es- timate the W mass.

 Why can the longitudinal momentum component of the W boson not be reconstructed?  How can you estimate the x and y components of the neutrino‟s momentum? (hint: think about the total transverse momentum before and after the collision).  How can you estimate the W mass from the transverse mass distribution?

5 27/08/2009

 Can you estimate the number of Z events in your W sample?

 Why do we have to recalculate 퐸/ 푇 using the momenta of the muon(s) in the event?  Why is it relevant that the muon is a “minimum ionising particle” (MIP)?

Determination of the Efficiencies The branching ratio BR 푊 ⟶ 휇휐 will be measured from the ratio of the W and Z production cross-sections. Some, but not all, efficiencies will cancel in this ratio if you use the same criteria for selecting the muons. Determine the total efficiencies for reconstructing W and Z events using the Monte Carlo. Calculate the trigger efficiency for MUW_W_L2M3_TRK10 using the independent trigger method (this assumes that you have selected only events which pass MUW_W_L2M3_TRK10). You must also determine the uncertainties on the efficiencies.

 Which assumptions are being made in the “independent trigger method”?  How can the muon reconstruction efficiencies be determined directly from real data and what is the advantage of this method compared to using the Monte Carlo?  Why is the binomial distribution used to determine the uncertainties?

The ratio of the production cross-sections for the W and Z bosons is 휎 푝푝 ⟶ 푊 + 푋 BR 푊 ⟶ 휇휐 푅 = , 휎 푝푝 ⟶ 푍 + 푋 BR 푍 ⟶ 휇+휇− where X denotes the other particles produced in association with the W and Z bosons. The number of events, N, is given by 푁 = 휎 ℒd푡 , where 휎 is the cross-section and ℒd푡 is the time-integrated luminosity. The integrated luminosities cancel in the ratio since only one data sample and trigger are used1. To extract BR 푊 ⟶ 휇휐 you need to use the theoretical cross-sections 휎 푝푝 ⟶ 푊 + 푋 = 23.7 nb and 휎 푝푝 ⟶ 푍 + 푋 = 7.18 nb. The branching ratio BR 푍 ⟶ 휇+휇− has been measured at LEP to be BR 푍 ⟶ 휇+휇− = 3.366 ± 0.007 %.

1 The measured integrated luminosity for this data sample is ℒd푡 = 112.6 ± 7.3 pb−1.

6 27/08/2009

Compare your results with the measurements summarised by the Particle Data Group at http://pdg.lbl.gov.

7 27/08/2009

APPENDIX Navigating the code The first thing you need to do is to copy the example code to your account‟s home directory (it‟s important that they go there otherwise ROOT will not be able to find them later). The files that you need are all found in C:\dzero\Files To Copy\. You can use the NotePad++ editor to modify these copies as you go. Just drag-and-drop the files from your home directory onto the NotePad++ icon on the desktop to open them.

You will write a C++ class to carry out your analysis. There is an example class called MyAnaysis. Its header file, which contains the definition of the class member functions and variables (known as its interface) is MyAnaly- sis.h. The actual C++ code for these functions is in MyAnalysis.cpp. These are the two files you will edit as you implement your analysis. Either make changes directly to the copies you have in your home directory, or just use them as templates to write your own classes. There are lots of comments in these files, so take a moment to read through them before starting to write your own code.

The MyAnalysis class has three important functions in addition to the usual C++ constructor and destructor. These are:

Setup(), Event(const Data &theData), End().

There is also an example function, hasAtLeastTwoMuons, which is an example of a simple function to check if the event contains at least two muon candidates of good quality.

The Event function is called every time a new event has been read from the data file. Each time it is called, the data for the event are put into a Data object that is passed to your Event function. You can see the variables that contain the event‟s information by looking at the Data class‟ interface file, Data.h, which can be found in c:\dzero\inc\wz. The two functions Setup() and End() are called just before the first event is loaded and just after the last event has been processed respectively. They are there to let you do any initialisation or post-processing calculations that you might need.

8 27/08/2009

To perform the analysis and run over the data you need to compile your analysis class and load it into root. You do this within the ROOT program itself. There are some simple steps to do this.

1. Compile your class. To compile the example class, do the following:  At the ROOT prompt, type .L MyClass.cpp+ (the + at the end is important!) 2. If your C++ has compiled correctly you now need to make what is called an instance of your class. Doing this hooks it into some special code that we have added to root to make accessing the data easier for you. You do this simply by creating a new object of your class: Assum- ing your class is called MyAnalysis:  At the ROOT prompt, type MyAnalysis *m = new MyAnalysis();

The magic of C++ ensures that once you have created an object of My- Class it is automatically connected into the analysis framework. The only thing you have to remember to do is to delete the object if you change your analysis code before you run again. You do this by:

 At the ROOT prompt, type delete m;

Technical aside: You can create as many instances of your analysis classes as you like in root. Each one will be hooked into the analysis code automatically, and each one will be run in turn in the order you created them on each event. So, you could write three separate classes, with different names, one each for analysing real data, Z Monte Carlo and W Monte Carlo. You need to make a separate instance of each class by using new and getting a pointer to it (remember to use a new variable to store the pointer each time or you‟ll lose track of your ob- jects). Remember to delete the instance if you don‟t want it any more or if you change the code in the class.

3. Now you need to run over the data. You do this by using the RunOver method of a special D0Analysis class that we have built in to ROOT for you. First you need to get a pointer to the D0Analysis object in root:  At the ROOT prompt, type: D0Analysis *d = D0Analysis::GetInstance();

9 27/08/2009

 Now use this pointer to run over the data. The RunOver member function takes an argument that tells it which data file to look at. There are three values it understands, D0Analysis::RealData, D0Analysis::ZMonteCarlo and D0Analysis::WMonteCarlo. To run over the Z Monte Carlo, at the ROOT prompt, type: d->RunOver(D0Analysis::ZMonteCarlo);

To run over the other data files, just change the argument to the function. You should only need to get the pointer to the D0Ananlysis class once, the first time that you need it, but you can always get it back again by using the GetInstance method above. Your analysis class is automatically told what kind of data it is running over. You can find out by looking at the member variable _dataType, which will be set to one of RealData, ZMonteCarlo or WMonteCarlo.

The example class we have given you shows you how to create, fill, print and save some histograms. The comments in the files explain what the code does. You will also find a lot of reference material (some useful, some not so useful) on the ROOT website, http://root.cern.ch.

Running ROOT Root is an object-oriented data analysis framework written in C++. It pro- vides an interpreter, a compiler and many C++ classes to aid in the analysis of events. The interpreter allows a user to run code without first compiling it. The ROOT home page, with much more information and reference material, can be found at http://root.cern.ch.

To run ROOT simply double-click the ROOT icon on the desktop. When ROOT is running correctly you will get a prompt at which you can type C++ commands and ROOT instructions. For example, you can type cout << “Hello World” << endl; or anything you learned in the C course last year. You could use it as a calcu- lator if you wanted to. To compile and load your analysis code type

.L MyAnalysis.cpp+

10 27/08/2009

(change the name appropriately if you have a different class. The + at the end of the line is important!). This command runs the compiler and loads the compiled version of your code into ROOT. If you have any problems compiling the code, refer to the line numbers specified in the error messages. These er- rors are most likely due to mistakes in your code which you need to fix. Be- ware that if you miss out a semicolon or brace somewhere these line numbers may not be the source of the problem. If you still can‟t find what‟s wrong, ask a demonstrator.

Once the code is compiled and loaded into ROOT you can run it by following the instructions above. A complete example of the commands you would type the first time you run ROOT could be:

.L MyAnalysis.cpp+ MyAnalysis *m = new MyAnalysis(); D0Analysis *d = D0Analysis::GetInstance(); d->RunOver(D0Analysis::RealData);

In this example, D0Analysis::RealData tells the program to run on the data from the experiment. Use D0Analysis::ZMonteCarlo to run over the Z Monte Carlo or D0Analysis::WMonteCarlo to run over the W Monte Carlo data. The real data will take the longest to run as there are many more events in that dataset. If all works correctly, you should see a progress bar telling you how much of the data has been processed and how long it will take to analyse the rest. You can stop the analysis job at any point by clicking the “stop” button. This will terminate the loop over events in the file and call the End function in your analysis class.

Using the ROOT Browser To open the browser, type new TBrowser; at the ROOT prompt. This opens a browser window that can be used to navi- gate ROOT files, including the data files provided and the files containing histograms generated in your code.

Creating Histograms The best way to see how to create histograms is to look at the example source code provided in MyAnalysis.cpp and MyAnalysis.h. Pointers to the histograms are declared in the header file and the histograms themselves are

11 27/08/2009 created in the Setup function. You will see that there are two example histograms which you can copy, but remember to give them their own unique names if you want to re-use them.

Getting the correct number of bins in your histograms is important. Too many and you won‟t be able to reliably fit functions to the data later on, too few and you‟ll lose details that you might need. The histograms are filled by adding entries each event using the hist->Fill( value ) function. Each histogram is a representation of the data that lie within discrete boundaries of a certain size – this is the “bin width”. The “number of bins” parameter defines this bin width as it says how many boundaries there are between the maximum and minimum value of the histogram. Remember that any value you try to put into a histogram that is below the minimum or greater than the maximum value you chose when you created the histogram will be lost.

How to Fit a Function to a Histogram An example of how to fit a histogram with a function is shown below. When you need to do it, put all the code into the End() function, after the histograms have been filled.

The first step is to build a function object that you will use to fit the histogram. It will have some free parameters which will be used by the fitting mechanism behind the scenes, adjusting them until the best fit is achieved. The parameters are passed in a string and use a specific format. The first parameter is called [0], the second [1] and so on. An example function – a second order polynomial – is constructed below:

TF1 *MySecondOrderPolynomial = new TF1(“my_name”,”[0] + [1]*x + [2]*x*x”,0,100);

The fist argument is just the name of the function – you choose it and it must be unique. The second argument is the actual function itself. In this case there are 3 free parameters [0], [1] and [2]. These are the parameters that are varied during the fitting procedure. x is a variable that is automatically calculated by ROOT during the fit to work out the value of the function at a particular point. The last two arguments determine the range over which the function is valid. You will need to create the function object in your class somewhere (probably in the End function). Remember, if you use a new ROOT class you will also need to include the appropriate header in your code so that the compiler knows how to use it.

12 27/08/2009

Before you try to carry out a fit, you have to give the free parameters some sensible starting values. Do this as shown in the example below:

MySecondOrderPolynomial->SetParameter(0, 1.2); MySecondOrderPolynomial->SetParameter(1, 5.3); MySecondOrderPolynomial->SetParameter(2, -2.1);

Then, if you have a histogram pointed to by the pointer variable histo, you carry out the fit with the command histo->Fit(MySecondOrderPolynomial,”R”);

The second argument, the option “R”, performs the fit over the range defined by the function. This allows you to fit a function over ranges that are smaller than the range covered by your histogram. You need to make sure you have enough histogram bins with sufficient entries in each bit to allow the fit to work, hence the necessity for getting the number of bins and ranges for your histograms correct. This usually requires some optimisation.

Do I need to know C++? C++ is an extension of the C programming language to include object orienta- tion. You should know enough C programming from last year‟s course to complete this experiment – most of the C++ parts are hidden away from you. One of the most basic ideas in C++ is that the majority of the code is organ- ised into classes. Each class has a set of data and functions associated with it. The D0Analysis class actually does all the hard work of reading the data. The glue between it and your analysis class is handled by a feature of C++ called inheritance, implemented by deriving your analysis class from another called AnalysisBase. It is the AnalysisBase class that hooks your code into the D0Analysis class. If you need to extend your analysis class, add variables and functions in the place indicated in the example code. Always remember to save your changes and recompile before running your analysis code again.

Data Description The following variables are available in the ROOT tuples and are defined in the file Data.h. All momenta and energy measurements are in GeV (with 푐 = 1). “Transverse” always refers to the component perpendicular to the beam (which is defined to be the 푧 axis). 휙 is the azimuthal angle and 휃 the polar angle. The polar angle 휃 is usually expressed in terms of the pseudorapidity 휂 = − ln tan θ 2 . In the data, all the variables listed in the tables

13 27/08/2009 below are prefixed by their branch name and an underscore. For example, the event number is store in the variable EVT_event, and likewise for the other branches.

 EVT Branch

This branch contains general event quantities

event event number run run number

 MET Branch

This branch contains the transverse energy as measured by the calorimeter. It does not include the momenta of the muon(s) in the event. Its 푥 and 푦 components are calculated by summing up the vector momenta for all the particles detected in the calorimeter for a particular event. If a particle (such as a neutrino) escapes without being detected, it manifests itself as an apparent violation of conservation of momentum. The 푥 and 푦 components of the neutrino momentum are, there- fore, equal to minus the 푥 and 푦 components of the missing total transverse energy.

met total calorimeter transverse energy met_x 푥 component of calorimeter transverse energy met_y 푦 component of calorimeter transverse energy

 MU Branch

This branch contains particle properties as measured in the tracking and muon systems. Before using this branch, the muons are sorted by their transverse momenta. This is done automatically for you, and the

indices of the two highest 푃푡 muons are stored in the variables index1 and index2 inside the Data class.

Nmu number of muons in the event px 푥 component of the muon momentum (central tracker) py 푦 component of the muon momentum (central tracker) pz 푧 component of the muon momentum (central tracker)

14 27/08/2009

pt transverse momentum of the muon (central tracker) ptl transverse momentum of the muon (muon detector) pt_5 sum of transverse momenta of central tracks in a cone of radius 푅 = Δ휂 2 + Δ휙 2 = 0.5 around the muon direction (excluding the muon) ehalo transverse component of energy measured in the calorimeter, 퐸푇 = 퐸 sin 휃, in an annulus 0.1 < 푅 < 0.4 around the muon isMedium muon with medium quality criteria (used in the analysis) hasCentral muon found in muon system has a central track matched to it chisqdof 휒2 per degree of freedom for the track fit (= quality of track fit) smt_hits number of hits in the Silicon Microstrip Tracker (SMT) cft_hits number of hits in the Central Fibre Tracker (CFT) eta pseudorapidity 휂 = − ln tan 휃 2 of the track phi azimuthal angle, 휙, of the track q charge of the muon timeA time measured by scintillators if a scintillator hit is present (measured with respect to the beam cross- ing time) dca ignore this one!  TRIG branch

This branch contains the list of trigger conditions that are fulfilled for this event. You only need to use MUW_W_L2M3_TRK10, which is defined as:

o Level 1: Trigger on a single muon in the region 휂 < 1.5 o Level 2: Pass events with at least one muon found with transverse momentum greater than 3 GeV/푐, measured in the muon system. o Level 3: The trigger bit is set to true if one track is found with transverse momentum greater than 10 GeV/푐, measured in the central tracking system.

15 27/08/2009

The variable TRIG_Independant indicates that one of several calorimeter trigger conditions have been fulfilled for this event. The calorimeter trigger is independent of the muon system.

Useful Links  DØ home page: http://www-d0.fnal.gov/public/index.html  ROOT home page: http://root.cern.ch  Particle Data Group: http://pdg.lbl.gov  Live event displays from DØ: http://www.fnal.gov/pub/now/live_events/dzero_live.htnl

16 27/08/2009

Event Displays These event displays show some events with two muons:

Figure 2: Four 풁/휸∗ to muons event displays in the 풓흓 view of the detector (end on to the beam). The inner part, with the concentric circles, shows the SMT and CFT tracking detectors. Tracks are shown as curved lines. The outer ring represents the amount of energy deposited in the calorimeters. Missing transverse energy (not corrected for the muon momenta) is shown by the yellow block. Muons in the A, B and C layers are shown as red, orange and green bars outside the calorimeter.

17 27/08/2009

Figure 3: Four 풁/휸∗ to muons event displays in the 풓풛 view of the detector. The inner part shows the SMT tracking detectors. Tracks are shown as curved lines. The outer section represents the amount of energy deposited in the calorimeters. Muons in the A, B and C layers are shown as red, orange and green bars outside the calorimeter.