UBC Undergraduate Research

Searching for Stable Massive Particles in the ATLAS Transition Radiation Tracker. Schramm, Steven 2011-05-10

You don't seem to have a PDF reader installed, try download the pdf

Item Metadata


52966-Schramm_Steven_UBC_2011_Physics_449_Honours_Thesis.pdf [ 548.52kB ]
JSON: 52966-1.0085965.json
JSON-LD: 52966-1.0085965-ld.json
RDF/XML (Pretty): 52966-1.0085965-rdf.xml
RDF/JSON: 52966-1.0085965-rdf.json
Turtle: 52966-1.0085965-turtle.txt
N-Triples: 52966-1.0085965-rdf-ntriples.txt
Original Record: 52966-1.0085965-source.json
Full Text

Full Text

Searching for Stable Massive Particles in the ATLASTransition Radiation TrackerbySteven SchrammA THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFBachelor of Science (Hons)inTHE FACULTY OF SCIENCE(Physics and Astronomy)The University Of British Columbia(Vancouver)April 2011c Steven Schramm, 2011AbstractThe search for new particles is an important topic in modern particle physics. Newstable massive particles are predicted by various models, including R-parity con-serving variants of supersymmetry. The ATLAS Transition Radiation Tracker canbe used to look for charged stable massive particles by using the momentum andvelocity of particles passing through the detector to calculate its mass. A programnamed TRTCHAMP has been written to perform this analysis.Recently, ATLAS changed their data retention policies to phase out the useof a particular format of output file created during reconstruction. TRTCHAMPrelies on this file type, and therefore this change prevents the algorithm from work-ing in its original state. However, this problem can be resolved by integratingTRTCHAMP into the official reconstruction, which has now been done.This paper documents the changes involved in integrating TRTCHAMP withthe existing InDetLowBetaFinder reconstruction package. Topics discussed in-clude the structure of reconstruction algorithms in ATLAS, the retrieval of calibra-tion constants from the detector conditions database, and the parsing of necessaryparameters from multiple reconstruction data containers. To conclude, the outputof TRTCHAMP is shown to accurately estimate the velocity of protons in mini-mum bias tracks. Additionally, mass plots generated with the TRTCHAMP resultsare shown to agree with the known mass for both monte carlo and real protons inminimum bias tracks, and agreement is shown between the input and output massesfor a monte carlo sample of 300 GeV R-Hadrons.iiTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 New Particles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Our Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1 Tracking Charged Particles in the TRT . . . . . . . . . . . . . . . 62.2 Estimating Relativistic Velocities in the TRT . . . . . . . . . . . . 83 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Reasons for Switching to Reconstruction . . . . . . . . . . . . . . 133.2 Private Algorithm Implementation . . . . . . . . . . . . . . . . . 153.3 Reconstruction Implementation . . . . . . . . . . . . . . . . . . . 153.3.1 LowBetaAlg . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Retrieving TRTCHAMP Calibration Priors . . . . . . . . 183.3.3 Compiling TRTCHAMP Input Parameters . . . . . . . . . 194 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21iii4.1 Comparing the Old and New TRTCHAMP . . . . . . . . . . . . . 214.2 Velocity Residuals . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Monte Carlo Mass Plots . . . . . . . . . . . . . . . . . . . . . . . 224.4 Data Mass Plots . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1 Calibration Database Problems . . . . . . . . . . . . . . . . . . . 265.2 Refitted Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.1 LowBetaAlg.h (Wrappers Header) . . . . . . . . . . . . . . . . . 34A.2 TrtToolsWrapper.cxx (Wrappers Body) . . . . . . . . . . . . . . 37ivList of FiguresFigure 2.1 Cross section diagram of a TRT straw . . . . . . . . . . . . . 7Figure 2.2 A particle track in the TRT . . . . . . . . . . . . . . . . . . . 9Figure 2.3 Track timing diagram for a particle moving with b 1 . . . . 11Figure 2.4 Track timing diagram for a particle moving with b < 1 . . . . 12Figure 3.1 Stages in the data acquisition and analysis process . . . . . . 14Figure 4.1 Relative residuals for the TRTCHAMP velocity estimator . . 23Figure 4.2 Reconstructed Mass Plot of Monte Carlo Protons . . . . . . . 24Figure 4.3 Reconstructed Mass Plot of Monte Carlo 300 GeV R-Hadrons 24Figure 4.4 Reconstructed Mass Plot of Real Data Protons . . . . . . . . 25vGlossaryAOD Analysis Object DataATLAS A Toroidal Lhc ApparatuS, one of the detectors at the LHCCHAMP CHArged Massive ParticleESD Event Summary DataLHC Large Hadron Collider, a particle accelerator in Geneva, SwitzerlandLSP Lightest Supersymmetric ParticleROOT A C++ object-oriented framework for high energy physicsSMP Stable Massive Particle, a long-lived massive particleSUSY SUperSYmmetryTRT Transition Radiation Tracker, a subdetector in ATLASTRTCHAMP The program used to search for CHAMPs in the TRTWIMP Weakly Interacting Massive ParticleviAcknowledgmentsI am grateful to the UBC ATLAS group for all of the support I have received overthe past year, and for fostering my knowledge of particle physics. In particular, Iwould like to thank my supervisor, Prof. Colin Gay, for giving me the opportunityto pursue my academic dreams.I also wish to give my most sincere thanks to Bill Mills, of the UBC ATLAS group.His continual assistance and encouragement, thoughout the course of my thesis,was greatly appreciated.viiChapter 1IntroductionThe Large Hadron Collider (LHC), based in Geneva, Switzerland, is currently thehighest energy particle accelerator in the world. Now that the LHC is operationaland colliding beams of protons as intended, the search for new physics has begun.With a current collision energy of up to 3.5 TeV per beam, there is the potential forthe discovery of new particles, which would be monumental. The Standard Modelof particle physics predicts the existence of an as of yet unobserved particle, knownas the Higgs boson. The search for the Higgs boson has been highly publicized,and the discovery of the Higgs boson would be a major accomplishment that istheorized to be within the LHC energy range[11].While the Higgs boson would certainly be a notable discovery, it is not the onlynew particle that may be discovered. There may be many other exotic particles justwaiting to be found by the LHC.1.1 New ParticlesWith higher collision energies, more massive particles can be discovered. This isdue to the relation between energy and matter, as laid out by the relativistic energy-momentum relationship:E =q(mc2)2 +(pc)2 =) m = 1c2qE2 (pc)2New particles will have to be extremely massive to have not been discovered1by previous particle collider experiments, such as those conducted at Fermilab.Of these massive particles, some of them are expected to be stable, earning themthe name of Stable Massive Particles (SMPS). In the recent past, charged SMPswere also known as long-lived CHArged Massive Particles (CHAMPS), but morerecently the designation of SMPs has been used in academic papers. Many suchSMPs are theoretically observable by the LHC detectors, such as the A Toroidal LhcApparatuS (ATLAS) Experiment’s Hadronic Calorimeter[2]. In fact, such particleswould stand out in collisions, due to their large mass resulting in less availablespace for kinetic energy. As all known particles will be moving at approximatelythe speed of light in a 3.5 TeV per beam collision, any particle with a large massthat is detected to be moving significantly slower is an exotic particle candidate.The search for SMPs has a strong theoretical backing, including the supportof SUperSYmmetry (SUSY), one of the prominent theoretical models of particlephysics beyond the Standard Model. There are a large number of supersymmetricmodels, many of which predict the existence of some form of SMP. In SUSY, eachparticle in the Standard Model has a supersymmetric partner particle. Additionally,supersymmetry introduces a new parity, called R-Parity, which has an associatedvalue of +1 for every particle in the Standard Model and -1 for each superparticle.Some SUSY models enforce a conservation of R-Parity, which then requires theLightest Supersymmetric Particle (LSP) to be stable, as there is nothing that it candecay into. Additionally, the decay of the second lightest supersymmetric parti-cle will be supressed due to only having a single possible decay mode, the LSP.Therefore, this creates a set of possible SMPs to investigate.The search for SMPs has numerous applications to further research, and couldeven provide answers to some of the mysteries of high energy physics. For exam-ple, if a supersymmetric SMP is discovered, it could provide the first experimentalvalidation of supersymmetry, which in turn could supply solutions to two of themost important puzzles in modern particle physics. First off, SUSY presents a so-lution to the hierarchy problem related to the Higgs boson by the existence of asuperparticle partner for each normal particle, which leads to a cancellation of thequantum corrections to the Higgs mass[9]. Secondly, the LSP is generally expectedto be a Weakly Interacting Massive Particle (WIMP), and this WIMP is thought tobe a primary candidate for the source of dark matter in the universe[6]. As such,2validating or constraining the model parameters of SUSY by searching for SMPs isa definite possibility at the LHC[5], and would be a major accomplishment.Supersymmetric particles are by no means the only exotic particle candidatesthat could be observed at the LHC. However, they are examples from one promi-nent theory that have been shown to have theoretical masses within the range ofthe LHC[5], either now at 3.5 TeV per beam or later after the 2012 upgrade to 7TeV per beam.1.2 Our ProjectOur project focuses on using the Transition Radiation Tracker (TRT), which is partof the inner detector of the ATLAS experiment, to search for SMPs. As such, thispaper will focus on the methods used in the ATLAS experiment from now on, unlessotherwise specified. The TRT can detect charged SMPs by measuring the momen-tum and relativistic velocity, b, of particles passing through the detector. If theresulting b value is small compared to the speed of light, then the observed TRTevent may involve a new massive particle, which can then be investigated in moredetail. This is all of the information needed to determine the mass of a particle, asper the following relativistic momentum equation:~p = gm~v =) m =j~pjp1 b2bcAs the LHC continues to operate, our understanding of the collider improves,allowing us to increase its luminosity. Luminosity, a measure of the number ofparticles per unit area, per unit time, is related to the number of collisions that occurin a given amount of time. Therefore, as the luminosity of the LHC is increased,larger and larger quantities of raw data will be available. Increasing the amount ofraw data leads to a data storage problem, as the data acquisition hardware can onlyprocess a set amount of information in a given time period. This creates the needfor hardware triggers to differentiate between interesting and uninteresting events(individual collisions and their products), and to then only store the raw data forinteresting events.Events that have passed the hardware triggers must then be converted from raw3electrical signals into physical quantities, such as 4-vectors. The process by whichthis is done is known as reconstruction, and is managed by a program called Athenain the ATLAS experiment. Athena combines the observations of all of the subde-tectors in order to recreate the paths of particles as they move through the ATLASdetector, in addition to determining measurements of the particles within each in-dividual detector. For our project, the relevant information is that reconstructioncalculates the 3-momentum and direction of particles that pass through the TRT.As such, in order to determine the mass of particles in the TRT, we are left with therequirement of measuring their velocity.Before this project, the program used to calculate particle velocities in the TRTwas executed during data analysis, which is in a separate processing pass multiplesteps beyond reconstruction. As a result, this program relied upon a certain set ofparameters and data to be generated by the reconstruction stage and retained untilthe analysis stage. This was adequate at first, but with the luminosity upgrades,the data throughput was becoming too large to handle. To remedy this problem,ATLAS controllers decided to discard some of the data past the reconstruction stage,including some of the parameters the old analysis program depended upon for cal-culating the velocity of particles. Due to this change, it became very important tomigrate the velocity calculation routines from the analysis stage into Athena.In addition to allowing the search for SMPs in the TRT to continue and de-creasing data throughput by around six orders of magnitude[4], this change alsoprovides a key new feature in the reconstruction. In the past, the velocity of par-ticles in the TRT was calculated by and available to only our research group, as itwas done with a private algorithm. With the algorithm integrated into the officialreconstruction process, the particle velocity estimate is available for anyone to use.This change provides new functionality to Athena, which in turn gives everyone inthe ATLAS experiment access to additional information about events that they maywish to analyze.As the LHC luminosity continues to increase, this project becomes more andmore important. Our changes aim to drastically decrease the data throughput re-quired for the search for SMPs in the TRT by integrating a post-processing analysisscript into Athena, the official canonical reconstruction for the ATLAS experiment.However, even if there were no data limitations, our project still would be benefi-4cial because it adds additional information, in the form of the relativistic velocityof particles in the TRT, to reconstruction for use by others.5Chapter 2TheoryIn order to fully understand the computational requirements of this project, themeans by which the relativistic velocity b = v=c is obtained must be discussed.This first requires an explanation of how the TRT conducts its primary purpose,which is to track particles as they move through the detector.2.1 Tracking Charged Particles in the TRTThe TRT is a combined transition radiation detector and straw tracker, which con-tains approximately 300,000 straws. Each straw is comprised of a central anode,an outer wall held at a highly negative voltage with respect to the anode, and a gasmixture of 70% xenon, 26% carbon dioxide, and 3% oxygen[13], a cross-sectionof which is shown in figure 2.1. As a charged particle passes through the straw, itionizes the gas, which is referred to as a “hit”. These electrons then move to theanode due to the influence of the electric field generated by the straw wall to anodepotential difference. The anode records the arrival of electrons as electrical signals.These electrical signals can then be used to recreate the path of the charged particle,as the amount of time it takes an ejected electron to reach the anode depends on itsdistance from the anode. An electron ionized at the straw wall will take 45ns[10]to reach the anode, while an electron that is ejected arbitrarily close to the centerof the straw takes essentially zero time to reach the anode. The time at which anelectron would reach the anode if the charged particle were to pass arbitrarily close6Figure 2.1: The cross section of a straw in the TRT. The red circle in themiddle is the anode, while the outer red circle is the straw wall, held at-1500V with respect to the anode. The space in between is filled with agas comprised of 70%Xe, 27% CO2, and 3% O2. As charged particlespass through the straw, they ionize the gas. These electrons move tothe anode, due to the potential difference between the anode and strawwall. The anode records the arrival of electrons as electrical signals,and can use the difference between the start time, t0, and the arrival ofthe first electron to determine the point of closest approach, which isrepresented by the drift circle. A series of these drift circles can be usedto reconstruct the path of the charged particle.to the anode is called the t0 value, and is the start time for TRT calibrations.On average, a charged particle will generate seven such hits per straw, meaningthat the anode will usually record an electron from approximately the straw wall,as well as an electron from approximately the point of closest approach. Addition-ally, particles are assumed to be moving at nearly the speed of light (b  1), andtherefore each of those hits will occur at approximately the same time relative tohow long it takes for the electron to reach the anode. As the time at which thefirst electron would be observed if the charged particle passed arbitrarily close tothe anode is known, and has value t0, we can determine the point of closest ap-7proach. Specifically, the difference between the t0 value and the actual arrival timeof the first electron can then be used to reconstruct the radius of closest approachfor the charged particle, which is known as the drift circle radius, and which has acorresponding drift circle as shown in figure 2.1.A single drift circle does not give the trajectory of the charged particle, as wenow have a circle of points at which the particle may have passed. However, acharged particle also does not pass through just a single straw. We can combinea series of drift circles, corresponding to a series of consecutive straws traversedby the same particle, to reconstruct the path taken. This is possible because theaverage charged particle in the TRT passes through thirty straws, to generate whatis called a track, an example of which is shown in figure 2.2. Using all of the strawsin a path allows us to recreate the trajectory of the particle by fitting a curve to bebest-tangent to all of the corresponding drift circles, which is also shown in thesame figure.Now that we have a means of recreating the track a particle took through theTRT, we must turn to velocities. Unfortunately, the TRT was not designed to calcu-late the velocity of charged particles as they pass through the detector. However,we can exploit the assumption that particles are moving with b  1 to obtain anestimate of their actual velocity.2.2 Estimating Relativistic Velocities in the TRTThe electrons generated by the traversal of a straw by a charged particle can beused to construct a timing diagram. We know the time at which the first electroncan possibly reach the anode, as this corresponds to the particle passing arbitrarilyclose to the anode. Therefore, this is the earliest possible rising edge time, andif the anode receives an electron before this point, we know that a problem hasoccurred. Otherwise, the rising edge of the timing diagram is simply the time atwhich the first electron reaches the anode, which corresponds to the approximatepoint of closest approach of the charged particle. The falling edge is then the finalelectron to reach the anode, which is from the straw wall, and therefore shouldbe exactly 45ns after the earliest possible rising edge time. As part of the corefunctionality of the TRT implementation, it is calibrated under the assumption that8Figure 2.2: A charged particle path passing through five straws to create atrack. The solid red circles are straw walls, dashed red circles are driftcircles, and the blue path is the reconstructed track of the particle, whichfollows the drift circles. The interaction point is where the actual eventoccurred, and the straws are numbered to show the order in which thecharged particle passed through them.charged particles are moving at approximately the speed of light, or with b  1.This results in all of the falling edges of all of the straws in a track being aligned ina timing diagram, with the straw distance from the interaction point as the verticalaxis. If the particle is actually moving near the speed of light, as per the assumptionmade by the calibration, then the timing diagram works out as shown in figure 2.3.However, we are interested in particles moving slower than the speed of light.In this case, the ionizing radiation will not arrive at the nominal times correspond-ing to a track from a b  1 particle, but will rather be delayed by an amountdetermined by its actual velocity. This will cause the timing diagrams to have de-layed falling edges, as the t0 value is off. That is, the particle will actually enter aparticular straw a time t after the calibration assumed that it would, and thereforethe arrival of the first electron in the straw will occur a time t after it was expectedto. The value of t will increase with the distance from the interaction vertex, as the9charged particle falls further and further behind the assumption, as shown in figure2.4. The rate at which the particle falls behind can be related to the delay betweenthe falling edges of sequential straws, which gives us an estimate on the relativisticvelocity of the charged particle as it moves through the TRT.10Figure 2.3: Timing diagram for the track of a particle moving with b  1.The vertical axis contains straws in the track. When the signal for astraw is high, the straw is receiving electrons from the ionized gas. Therising edge is when the first electron reaches the anode (from the closestapproach), while the falling edge is the arrival of the final electron (fromnear the straw wall). Line A marks the end of the last event, and B markswhere the rising edge of the related set of hits could begin if a particlemoving with b 1 passed arbitrarily close to the anode wire. The TRTis calibrated so that, for a particle moving with b 1, the falling edge ofall straws in a track occur at the same time. Line C shows this relationwith all the falling edges occuring 45ns after line B. In this diagram, theparticle passes closest to the center of the second straw, characterisedby the earliest rising edge, and furthest from the center of the first straw,as seen by the latest rising edge.11Figure 2.4: Timing diagram for the track of a particle moving with b < 1.This figure is a continuation of Figure 2.3, where now the particle ismoving slower than the speed of light. Lines A and B still have thesame meaning as before. As the TRT is calibrated to line up fallingedges for particles moving with b  1, a particle moving with b < 1will fall further and further behind by comparison. In this example, thefirst straw still observes the final electron at 65ns, while the second trackhas been delayed by 5ns and the third track by 10ns (relative to a fastparticle). Line C shows this relation. The delay between sequentialfalling edges can be used to determine b.12Chapter 3MethodsBefore discussing the actual changes that were made, it is useful to have an under-standing of the general process by which data is taken and analyzed in the ATLASexperiment. Figure 3.1 shows the flow of information and sequence of stages ofprograms when acquiring and analyzing data. The first stage is to select “interest-ing” events to record, managed by hardware triggers, so that we don’t overwhelmthe computer systems. The events that are retained are then stored as raw data,which is a digitized electrical signal. In the next step, the electrical signals areturned into physical quantities, such as 4-vectors, through the reconstruction pro-cess. This stage is also where selection cuts can be made, meaning software filterscan be applied to decide which information is relevant to a particular search or re-search group. The output of this stage is known as an Event Summary Data (ESD)file. From there, more selection cuts can be made, which results in Analysis ObjectData (AOD) files. These AOD files can then be used as input to various analysisscripts to obtain actual results.3.1 Reasons for Switching to ReconstructionBefore this project, the velocity estimator in the TRT took place in the private anal-ysis script stage, right at the end of the analysis chain, as shown in figure 3.1. Theprogram ran on inputs of ESD files, which created an implicit dependence on par-ticular outputs from the reconstruction stage. This was not a problem before, but13Figure 3.1: The computer programs and intermediary stages involved in ac-quiring and analyzing data in the ATLAS experiment, including calcuat-ing b in the TRT. Interesting events are selected, digitized, and read outfrom the TRT via hardware drivers, which results in raw data. Recon-struction converts these digitized electrical signals into physical quanti-ties, and then applies selection cuts, generating an ESD file. More cutsare applied to create AOD files, which are then used as input to useranalysis programs. TRTCHAMP used ESD files, although it was run afterAOD files were generated. The original program’s location in this chainis shown in red, while the velocity estimator’s new position as a part ofreconstruction is shown in blue.has become an issue due to a recent change in the ATLAS data retention policy. Dueto a significant increase in the luminosity of the LHC, the ATLAS group has beenforced to find ways to decrease data throughput, which is the amount of data beingwritten to and read from disk at any given time. To do this, they have elected tophase out ESDs, and have begun by deleting them six weeks after creation. Thisis important because only ESDs contain hit-level information, which is informa-tion that deals with the individual ionization events, as is needed for the timingdiagrams used by our b estimator. As such, if anything goes wrong and has tobe redone at a later point, this will no longer be possible. This change in the dataretention policy therefore requires our research group to integrate the b estimatorroutine into reconstruction stage if we wish to continue the search for SMPs in theTRT, as there will no longer be a guaranteed way to obtain all of our required inputsas a private analysis algorithm.Beyond this strict requirement, there are several benefits to our program beingpart of the official reconstruction. Once added to Athena, our algorithm will be runby default whenever reconstruction is run. Being part of reconstruction means thatwe will no longer have to run a separate processing pass afterwards to obtain ourresults, which in turn decreases the amount of time required for our research. An-other reason for our program to be a part of reconstruction is that we are calculating14a value of physical significance, which could be used by other research groups inthe future. Before our group’s project, there was an estimate of the speed of parti-cles as they passed through the TRT added by a different research group. However,our estimate is independent and competitive with theirs, so the two values can becompared to confirm both individual estimates. As such, by adding our programto Athena, other groups could benefit from our work and could use the b value fortheir own purposes.3.2 Private Algorithm ImplementationAs mentioned, the program was originally run during the user analysis stage, whichis the domain of private algorithms. TRTCHAMP was initially written and run us-ing an object oriented framework specifically designed for high energy physics(ROOT). ROOT is an extension of C++, with a set of new libraries, and which isinterpreted instead of compiled. This difference was not too important, because theC++ code can still be compiled like a normal program, so long as you properlyfind and include all of the relevant root libraries. It was a small but crucial step ofthe project to find the necessary libraries and then compile TRTCHAMP, in order toensure that no required ROOT functions were missing.The TRTCHAMP program was written before I started this project, and carriesout the actual b estimation given a prescribed set of inputs. The core functionalityof the program did not need to be changed at any point, although a few meth-ods for providing alternate forms of inputs were added. The program that callsTRTCHAMP, on the other hand, is what necessitated a major overhaul. As a pri-vate algorithm, TRTCHAMP was called by a program that read input parametersfrom ESD or AOD files. By integrating TRTCHAMP into reconstruction, this was nolonger an option.3.3 Reconstruction ImplementationReconstruction is a large and complicated task that involves calculating local physi-cal values within each individual sub-detector, and then combining the results fromthe full ATLAS detector to determine the global value of other physical quantities.This enormous task is managed by a program named Athena, which coordinates15the execution of many different algorithms. Each algorithm run by Athena mustconform to a three-stage process of initialization, execution, and finalization. Theinitialization and finalization stages are intended to be computationally inexpen-sive, while execution is generally a very intensive process.Athena itself is also ordered into a set of individual stages, which can be char-acterised as:1. General reconstruction setup routines2. Algorithm initialization stages3. Algorithm execution stages, where initialization was successful4. Algorithm termination stages5. Data output and general reconstruction termination routinesIf the initialization stage of a particular algorithm fails, then its respective executionstage is not called. This allows for the initialization stage to test the parameterswith which the reconstruction is being run, and to abort if it has detected that thealgorithm will not be successful under the given conditions. For example, if thealgorithm relies on having access to a particular set of calibration constants andthe constants are missing for whatever reason, then there’s no point in running theexecution stage of the program. In short, the initialization stage generally retrievesdata containers necessary for the execution of the algorithm. The finalization stage,on the other hand, generally releases these containers and frees up memory that thealgorithm used.These algorithms are sorted into packages, where each package has a specific,distinct purpose, and a central algorithm. Through coordination with the rest of theresearch group, and with the help of the package maintainer[8], we obtained spacefor the results of our b estimation routine in the InDetLowBetaFinder package (In-ner Detector Low Beta Finder). The InDetLowBetaFinder package already existedas an official reconstruction algorithm searching for slow moving particles in theInner Detector (of which the TRT is a part), so the addition of our program to thispackage simply adds additional information. To be specific, we were given twofloats per particle that passes the selection cuts, so the value of our b estimate in16the TRT and the error in that estimate are the two physical quantities that we haveadded to the reconstruction.3.3.1 LowBetaAlgThe central algorithm in the InDetLowBetaFinder package is called LowBetaAlg,and it implements the three stage framework just discussed. In order to integrateTRTCHAMP with LowBetaAlg, a set of wrapper functions was created. These wrap-per functions serve the purpose of providing an intermediary layer between the twoprograms, and ensuring that changes can still be made to LowBetaAlg in the fu-ture without breaking TRTCHAMP, and vice versa. This is possible because thetwo are relatively isolated entities that only interact through three very small codesnippets, with one corresponding to each stage (initialization, execution, and final-ization). In essence, these wrappers create a clear division between LowBetaAlgand TRTCHAMP, while at the same time providing a rigid framework for connectingthe two, thereby enforcing a clearly defined interaction.The initialization and finalization stages of LowBetaAlg call the respectiveTRTCHAMP wrapper method directly, meaning that so long as the LowBetaAlgmethod is called, the associated TRTCHAMP method will also be called. However,the execution stage is different. During the execution of LowBetaAlg, selectioncuts are applied to determine which particles are considered to be SMP candidates,and therefore which particles we need to calculate the velocity of. To ensure thatwe only calculate the b of relevant particles, the TRTCHAMP execution wrapper iscalled after the success of the first round of selection cuts. This is the one possiblepoint of future conflict, as the execution wrapper is not entirely self-contained. Itrequires a particular data container as input, but LowBetaAlg relies on it exten-sively as well, so removing the container would require a complete rewrite of theexecute stage of LowBetaAlg. As such, so long as LowBetaAlg is not entirelyre-written, the TRTCHAMP functionality should not be interfered with.The wrapper programs for TRTCHAMP fulfill two main purposes. The ini-tialization wrapper ensures that TRTCHAMP has access to the correct calibrationconstants, while the execution wrapper compiles the necessary data for the inputparameters of TRTCHAMP. The finalization wrapper only performs trivial tasks,17and therefore will not be discussed in detail. The code for the wrapper methodsis in appendix A. Note that the code for the TRTCHAMP and LowBetaAlg routinesare not included, as my project focussed on integrating the two with only minimalchanges to the core programs, and therefore they can be treated as black boxes forthe most part.3.3.2 Retrieving TRTCHAMP Calibration PriorsThe TRTCHAMP algorithm makes use of a set of calibration values, known as pri-ors, during the b calculation. The set of priors is a measure of the probabililitydistribution representing the likelihood of finding the falling edge in each possibletime bin, for particles moving with b  1. That is, there is one prior per time bin.This probability distribution and the associated priors are determined experimen-tally by recording the falling edges of a large sample set of minimum bias tracks,with momenta of greater than 5 GeV[10]. These tracks will be of particles movingwith b  1, as the heaviest minimum bias track is the proton, and thus a protonmoving with 5 GeV will be moving at approximately the speed of light. Therefore,we have a sample set of particles moving with b  1, and we can record in whichtiming bins the falling edges for these particles occur, giving us our prior values.These prior values must be generated on a regular basis in order to stay up todate with various detector conditions and calibrations. As this is a core part ofTRTCHAMP, we had to find a way to dynamically retrieve the correct set of priorsfor a given data set, during the execution of Athena. We were informed that the TRTconditions database supported such functionality[7], although the documentationon how to use the database was either sparse or outdated. The documentation thatdid exist noted that the database supports tagging[12], meaning that we could taga particular set of priors as having been active up to a specified time and date,therefore providing a way to ensure that the correct priors for a data set undergoingreconstruction are accessed. This seemed like an elegant solution to the problem,and so we decided to take this approach.Unfortunately, the TRT conditions database is challenging to work with, asthere are lots of little quirks that are easy to circumvent once you know what to do,but hard to figure out in the first place. Again, the lack of recent documentation was18a problem, but thankfully I was in contact with two individuals who had some fa-miliarity with the process. First, I was told to use a local database and link it to theconditions database for testing, and even given a sample local database generationscript[7]. Then, I was informed of some little tweaks that were needed to get the lo-cal database to be recognized by the conditions database during reconstruction[1].In the end, I managed to set up a local database with a set of priors, and to linkit to the conditions database. From that point, I was able to start on the code thatretrieves information from the conditions database, as now there was a database toread priors from.The code to retrieve data from the conditions database was much simpler, and iscontained in the initialization wrapper and an “update” method. The initializationwrapper simply loads a bunch of default priors, specifies the folder of the condi-tions database to connect with, namely our priors folder, and registers a callbackupdate function with the Athena detector information storage service (detStore).This means that we want to update our default priors to the most recent set of pri-ors in the database. Note that this is not what we want in the future, as we wantto work with tags representing timestamps. However, this implementation was in-tended to lay out the core framework, so that others can add tag support at a laterdate.The update function is called after all of the athena algorithm initializations,but before executions. This ensures that TRTCHAMP will not be left using the de-fault priors during execution. In order to replace these default priors, we retrieve acollection of containers from the (currently local) priors folder linked in the con-ditions database, parse the containers into a format similar to how TRTCHAMPstores the priors it needs to use, and then replaces the default priors being storedin TRTCHAMP with the versions from the database. At that point, the calibrationconstants we needed have been read from the conditions database, and are readyfor use by TRTCHAMP once it is asked to calculate b in the execute stage.3.3.3 Compiling TRTCHAMP Input ParametersThe execution wrapper, which parses data from two containers into the format ex-pected by TRTCHAMP, is much simpler. The inputs that TRTCHAMP requires are19the transverse momentum and pseudorapidity values associated with a given par-ticle track, and a bunch of information for every straw the particle passed throughin the TRT. Vectors are used to store all of the information needed on a per-hitbasis. This per-hit information is comprised of a word that describes whether themeasurement can be trusted, the global cartesian coordinates of the hit, channel in-dices, the drift circle radius, the track radius, and the timing calibration. All of thisinformation, except the track radii, can be obtained from the Track container. TheTrack container, as the name implies, holds all of the general data about a specificparticle track. This container is widely used, meaning that it is relatively simple toloop over all of the hits in a track and add the required information to a vector.The track radii, however, are not used by most groups. As such, it is not in-cluded in the Track container, making it much more challenging to obtain thisinformation. These track radii quantify the shortest distance from the anode to thetrack for each hit. If the track fits to the drift circle tangents perfectly, then the driftcircle radius and track radius will be equal. However, we have no reason to assumethat we have a perfect fit, and so we need both values for our b estimates.With TRTCHAMP as a private algorithm using ESDs, we solved the problem byrefitting the track of a particle to every ionization event (hit), and then recaclculat-ing the track radii. However, as the program is now a part of reconstruction, wehave access to the CombinedIndetTracks container. This container is an unslimmedversion of the Tracks container, meaning that it still has all of the track radii. Wecan access this data by retrieving the container from the Athena event informationstorage service (evtStore). Once we have done this, we can immediately retrievethe track radii without the need to recalculate them from the ionization events. Wehad to do this when TRTCHAMP was a private algorithm, so our new implementa-tion has the added bonus of saving some cpu time. More importantly, this solvesthe primary problem that this project set out to address. As the track radii and allof the other required data are obtained during reconstruction and processed imme-diately, TRTCHAMP no longer relies on ESDs, and therefore we no longer have toworry about them being phased out.20Chapter 4Results4.1 Comparing the Old and New TRTCHAMPAs the goal of this project was to integrate the existing TRTCHAMP implementationinto the official reconstruction, the most logical way to test that everything is work-ing is to compare the output of the two programs when run on the same data set.If the program has been integrated properly, then the two versions should give thesame b estimates. After I completed the addition of TRTCHAMP and the associatedwrappers to the InDetLowBetaFinder package, I sent the code to Bill Mills[10],the author of TRTCHAMP. He then performed various tests, and confirmed that thetwo programs were giving the same results, to within our precision. The small dif-ferences beyond our precision are due to the use of slightly different track radiusfitting techniques. The technique used in Athena can always be changed, but thereis no indication that any one of the options for fitters will outperform the others inan outright majority of cases, and so we decided to stick with the default fit thathad already been conducted, thereby saving computational time. Regardless of thisminor difference, the integration can be said to be successful, as the differences aresmall enough that the results of the two different TRTCHAMP implementations areidentical to within our precision.214.2 Velocity ResidualsOne way to confirm that the b estimator is working correctly is to generate a montecarlo data set of particles with known velocities. If this data is then used for recon-struction and TRTCHAMP, then you know what the actual velocity of each particleis, and can therefore determine the error in the estimate. If be is our estimate fromTRTCHAMP and bt is the true velocity used to generate the data set, then the relativeresiduals are defined as: be btbtIf we plot the relative residual value on the x-axis and the number of occurrences ofthis residual on the y-axis, we get figure 4.1. We can then fit a curve to the peaks todetermine how accurate our estimator is, which shows us that they are very nearlycentered around an error of zero, and have a small standard deviation from zero.This tells us that our estimator is performing reasonably well. The secondary peaksin this figure correspond to fake b 1 particles, which occur so often in minimumbias tracks that they were not completely supressed.4.3 Monte Carlo Mass PlotsNow that we have confirmed the velocity estimator is working as intended, wecan confirm that our mass estimates are accurate too. To do this, we created a setof monte carlo minimum bias tracks. As protons are the heaviest stable standardmodel particle, they will be the primary constituent of any minimum bias track inthe TRT. Therefore, if we apply TRTCHAMP to this data set, we should get the massof the proton, which is 938.272 MeV. It turns out, as shown in figure 4.2, that wedo get this result, to within our uncertainty. The barrel of the TRT gives a mass of938 0:3 MeV, with a standard deviation of 84 0:3 MeV, while the endcap givesa mass of 923 0:5 MeV and a standard deviation of 85 0:5 MeV. As such, thebarrel gave exactly the result we wanted, while the endcap gave the expected resultto within one standard deviation.In order to try something slightly more exotic, consider the R-Hadron. TheR-Hadron is a theorized supersymmetric particle, comprised of a supersymmet-ric particle and at least one Standard Model quark. There are many predicted R-22 (barrel)βRelative Residuals for FE -0.6-0.4- (UBC)TRTChamp = 7 TeVs 0.0002± = -0.0018 µ 0.0002± = 0.0695 σ (ec)βRelative Residuals for FE -0.6-0.4- (UBC)TRTChamp = 7 TeVs 0.0003± = -0.0091 µ 0.0003± = 0.0661 σFigure 4.1: A pair of plots for the relative residuals of the velocities of pro-tons selected from minimum bias tracks, as estimated by TRTCHAMP,created by Bill Mills[10]. The x-axis is the value of the relative residual,as defined by ([estimated b] - [true b])/[true b], while the vertical axisis the numer of occurrences of that residual value in the sample. Theleft figure is the results from the barrel of the TRT, and the right figureis the results from the endcap of the TRT. As can be seen, both setsof residuals are centered very close to zero, and have a small standarddeviation, so the estimator is performing well. The secondary peaks aredue to fake b  1 particles, which are so numerous in minimum biastracks that they can’t all be perfectly supressed.Hardrons, but it is generally expected that, if they exist, they will have a mass ofgreater than 100 GeV. This limit is due to constraints from past experiments, suchas those conducted with the Tevatron. Similarly to the previous case, let us create amonte carlo sample of 300 GeV R-Hadrons, and if our TRTCHAMP returns a massof 300 GeV, then that’s more proof that our program is working properly. Figure4.3 shows the results, where the barrel estimates are a mass of 298 1:1 GeV witha standard deviation of 41 0:9 GeV, and an endcap mass estimate of 286 1:2GeV with a standard deviation of 36 1:1 GeV. Therefore, the estimates of theparticle mass are relatively close to the actual (300 GeV) mass. This continues toshow that our algorithm is properly estimating the mass of SMPs being observed inthe TRT.23FE Reconstructed Mass (barrel) [MeV]400600800100012001400160018002000Events/20MeV020004000600080001000012000 (UBC)TRTChamp = 7 TeVsminBias MCProtons 0.3) MeV± = (938 µ 0.3) MeV± = ( 84 σFE Reconstructed Mass (ec) [MeV]0200400600800100012001400160018002000Events/20MeV050010001500200025003000350040004500 (UBC)TRTChamp = 7 TeVsminBias MCProtons 0.5) MeV± = (923 µ 0.5) MeV± = ( 85 σFigure 4.2: Mass plot of a monte carlo proton data set, created by Bill[10].The x-axis is the mass calculated for a given particle, in MeV, with binsof size 20 MeV. The vertical axis is the number of times a particle withthe specified mass was observed. The left plot is for the barrel of theTRT, and the right plot is for the endcap. Fitting a curve to the peak givesthe estimated mass and standard deviation in the mass, which are easilywithin one standard deviation of the actual proton mass of 938.272 MeV.FE Reconstructed Mass (barrel) [GeV]0100200300400500600700800900Events/20GeV020406080100120140160180200220240 (UBC)TRTChamp = 7 TeVs300GeV rHadrons MCrHadron 1.1) GeV± = (298 µ 0.9) GeV± = ( 41 σFE Reconstructed Mass (ec) [GeV]02004006008001000Events/20MeV020406080100120140 (UBC)TRTChamp = 7 TeVs300GeV rHadron MCrHadrons 1.2) GeV± = (286 µ 1.1) GeV± = ( 36 σFigure 4.3: Mass plot of a monte carlo 300 GeV R-Hadron data set, createdby Bill Mills[10]. The x-axis is the mass calculated for a given particle,in GeV, with bins of size 20 GeV. The vertical axis is the nuber of timesa particle with the specified mass was observed. The left plot is for thebarrel of the TRT, and the right plot is for the endcap. Fitting a curve tothe peak gives the estimated mass and standard deviation in the mass,which are easily within one standard deviation of the input R-Hadronmass of 300 GeV.244.4 Data Mass PlotsThe final set of results is of a proton mass plot with actual data. As before, weare expecting a mass of 938.272 MeV/c2. Looking at figure 4.4, we do get thisexpected result. Specifically, the data gives us a mass estimate of 946 0:2 MeVwith a standard deviation of 102 0:2 MeV in the barrel of the TRT, and a massof 914 0:4 MeV with a standard deviation of 115 0:5 MeV in the endcap. Theactual proton mass is within significantly less than one standard deviation of themass estimates given by both the barrel and endcap measurements. This meansthat we get the expected results with actual data, which strongly implies that theTRTCHAMP program is working as intended.As a brief note, figure 4.4 is less accurate than the previous figures due tohaving more than one source of error. For the monte carlo simulations, the exactmomentum is known, as it was one of the input parameters. Therefore the montecarlo uncertainties are due to solely the b estimate. On the other hand, the real dataset involved using both the measured momentum and velocity, and both of thesequantities have associated uncertainties.FE Reconstructed Mass (barrel) [MeV]400600800100012001400160018002000Events/20MeV020004000600080001000012000140001600018000200002200024000 (UBC)TRTChamp = 7 TeVsminBias Data 153565Protons 0.2) MeV± = (946 µ 0.2) MeV± = (102 σFE Reconstructed Mass (ec) [MeV]0200400600800100012001400160018002000Events/20MeV020004000600080001000012000 (UBC)TRTChamp = 7 TeVsminBias Data 153565Protons 0.4) MeV± = (914 µ 0.5) MeV± = (115 σFigure 4.4: Mass plot for a proton from an actual data set, created by BillMills[10]. The x-axis is the mass calculated for a given particle, inMeV, with bins of size 20 MeV. The vertical axis is the number of timesa particle with the specified mass was observed. The left plot is for thebarrel of the TRT, and the right plot is for the endcap. Fitting a curve tothe peak gives the estimated mass and standard deviation in the mass,which are easily within one standard deviation of the actual proton massof 938.272 MeV.25Chapter 5DiscussionThroughout this project, I encountered numerous problems stemming from a lackof organization in the ATLAS experiment’s computing framework. This absence oforganization was displayed in many ways including, but not limited to, a sparsedocumentation, a lack of high-level support algorithms to perform common tasks,obfuscated job control options, and large log files. These all came up while tryingto set up a local database to link with the calibration database, as discussed insection 3.3.2, and so I shall discuss this example in more detail below.5.1 Calibration Database ProblemsWhile attempting to implement a connection to the conditions database, I went tothe ATLAS TWiki[12], which is the general source of documentation, and searchedfor “conditions database”. The first link gives a summary that looks like it mightexplain the database, but when you click on the link, it says that the page no longerexists. Then, looking at the other results turned up by the search, there is nonethat is immediately apparent as dealing with the conditions database. The secondpage actually does have a useful link, but you won’t know this if you don’t alreadyknow that the conditions database is implemented in the COOL language, andtherefore is listed as “AthenaCool”. It was only through talking with others[7]and reading several related TWiki pages that I realized that the conditions databaseand AthenaCool database are the same thing. With this knowledge, you would26then expect the AthenaCool documentation to provide the answer of how to linkthe a local database into AthenaCool. It does give an explanation, but it turns outthat the syntax is incorrect, because it’s from a different revision of the ATLASsoftware. To find the correct syntax, you can look through other people’s code,thanks to LXR[3]. LXR is quite useful, but you have to already know what you’relooking for. Now, you have the right syntax for how to connect a local database tothe conditions database.From there, the next step is to add a command to the job options so that thedatabase is accessible at runtime. However, with the current job transform rou-tines, this process is obfuscated. The job transforms are intended to handle allrequests in a user-friendly way, and they do if you want to stick to a simple tasks.However, as soon as you have to change the job options for an individual stageof the reconstruction, it becomes quite challenging. By reading through the jobtransform routine, you can find that another routine is called, which in turn calls“skeleton.RAWtoESD.py”. This file contains the job options for the raw data toESD stage of reconstruction, and is where you have to put the command specifyingto link the local database into the conditions database. This effort to hide the actuallocation of the job options from the user may not be intentional, but either way, itwas hard to find.At this point, I must mention that all of this could be written as a high-levelsupport algorithm. The steps that are taken would be very similar for any otheraddition to the conditions database, and so it would be immensely useful for amethod to be written that performs all of the necessary actions for you, given acouple of input parameters. There is no need for every group that needs to workwith the conditions database to have to go through the arduous process of setting itup step by step.Now that everything is theoretically working, you have to test your code, whichis done by running reconstruction. However, reconstruction takes 15+ minutes ona data set containing a single event, so this is no quick task. Then, a 75,000+ linelog file is created detailing the reconstruction process. You have to know what typesof errors to look for and where in the file they might appear if you want to have achance of debugging any problems that may have occurred. It is possible to onlyview warnings and errors in the log file, but often you need the information around27the problems to determine possible causes, and therefore it’s generally impracticalto work only with warnings and errors.5.2 Refitted TracksThe calibration database was a nice example because it showed all of the problemsat once, but it was by no means the only time I encountered each of those problems.Before we found out about the CombinedInDetTracks container, we thought that itwas necessary to refit the tracks to obtain the track radii during reconstruction, likewe did when TRTCHAMP was a private algorithm (discussed in section 3.3.3). Todo that, we first had to find a flag somewhere in the inner detector job options file,and switch it to be on, thereby providing track refitting capabilities. I started outby checking the TWiki[12], to no avail. Next, I used LXR[3], and managed to findthe name of the flag that I wanted. However, I once again had to make use of thewell hidden “skeleton.RAWtoESD.py” file to actually enable this option.Once enabled, reconstruction started failing. After searching through the enor-mous log file, I managed to find a line that told me the refitting procedure was beingcalled more than once, and therefore there were conflicts preventing reconstructionfrom executing properly. After going back to the TWiki to read more about jobtransforms, I had an idea of what the problem might be. I knew that I had to set theflag in a conditional statement, but I didn’t know the name of the property that thecondition depended upon. From there, I had to use LXR to go through the sourceeven more, and I found the actual job control script that decides when the refit flagis on and when it’s off. That allowed me to determine which flag to watch for be-fore enabling the refit, and to make the appropriate changes. With that change, thereconstruction was successful.Later on, we were encountering more problems from the refit scheme, andasked the track reconstruction experts for help. Their response was to ask whywe were refitting in reconstruction instead of just using the CombinedInDetTrackscontainer, as the refit was never meant to be run during reconstruction[14]. We nowuse the CombinedInDetTracks container, as it’s easier and fixed all the problemswe had. Even now that I know the name of the container, I can search for it onthe TWiki and get nothing, as the page for the container has not been created.28A brief glance shows that other pages make reference to the container, but onlybecause they are using it, not because they are explaining what it is. This is aperfect example of a large problem that could have been entirely avoided withbetter documentation.29Chapter 6ConclusionsThe discovery of a new particle would be a major breakthrough, and could providethe first conclusive evidence of physics beyond the Standard Model. The existenceof SMPs is predicted by multiple theories, notably including R-parity conservingvariants of SUSY. Such SMPs should be observable in the ATLAS TRT, and if ob-served, the mass of such particles can be calculated from the momentum and ve-locity of the particle. The momentum of the particle is already measured, and soTRTCHAMP was written to estimate the velocity of charged particles as they passthrough the TRT.As a private algorithm, TRTCHAMP occurred after the raw data was convertedinto physical quantities, through reconstruction, and stored as ESD files. How-ever, to deal with increasing LHC luminosities and therefore increasing amounts ofdata, ATLAS has recently changed its data retention policy towards phasing out ESDfiles. Unfortunately, the new output formats don’t contain all of the informationTRTCHAMP requires. To resolve this problem, TRTCHAMP needs to be integratedinto the reconstruction stage, so that it has access to all of the data that it needs.In order to do this, the InDetLowBetaFinder package was modified to includetwo additional floats per particle that passes a set of SMP selection cuts, wherethe two floats represent the b estimate and the standard deviation in that estimate.The primary algorithm in InDetLowBetaFinder, LowBetaAlg, was then linked toTRTCHAMP through a wrapper interface. This interface was designed to mini-mize the chance of changes to either LowBetaAlg or TRTCHAMP impacting the30other algorithm, and performed three key duties. First off, the wrappers retrieveda set of specialized calibration constants from the TRT conditions database, whichTRTCHAMP needs to function. Next, the wrapper obtained the inputs necessary forthe execution of TRTCHAMP through reconstruction data containers, and reformedthem in the way that TRTCHAMP expects. Finally, the wrappers call the TRTCHAMPalgorithm, and store the results in the two aforementioned floats.Through this change, the wrappers ensure that the TRTCHAMP algorithm func-tions as it used to, although it is now a part of reconstruction instead of being anindependent analysis algorithm. These modifications allow the TRTCHAMP algo-rithm to continue to run, despite the changes to the ATLAS data retention policy.Additionally, as the b estimator is now a part of reconstruction, the value is nowavailable for others to use in their own research, and therefore this provides benefitsto the ATLAS collaboration, rather than just our research group.In section 4, we have shown that the algorithm accurately calculates the veloc-ity of charged particles in the TRT. We have also shown how this can then be usedto determine the mass of the charged particle, for both monte carlo data sets andusing real data. Therefore, the TRTCHAMP algorithm remains a valuable part ofthe TRT search for SMPs, and may help in the discovery or further analysis of newparticle(s).In the future, the interaction with the calibrations database could be improved.As mentioned in section 3.3.2, the wrapper retrieves the most recent copy of thecalibration priors from the conditions database. This works for now, but shoud bechanged in the future to include tagging. That is, sets of priors should be taggedwith a range of when they were valid, and the initialization wrapper should thencheck the time stamp of the data set that reconstruction is being run upon, andfrom that determine which set of priors to read from the calibrations database.Alternatively, there may be other ways to obtain the priors. A lot of work hasbeen required to do anything with the calibration database, and there may be someother system of maintaining priors that is easier to manage. Others in the lab arecurrently looking into such alternate approaches[10].31Bibliography[1] A. Alonso. Personal communication, 2011.!page(s) 19[2] Shoji Asai et al. Measuring lifetimes of long-lived charged massive particlesstopped in lhc detectors. Phys. Rev. Lett., 103(14):141803, Oct 2009.!page(s) 2[3] Brookhaven National Laboratory. LXR, 2011. URLhttp://alxr.usatlas.bnl.gov/.!page(s) 27, 28[4] C. Gay. Personal communication, 2010-2011.!page(s) 4[5] I. Hinchliffe et al. Precision susy measurements at cern lhc. Phys. Rev. D, 55(9):5520–5540, May 1997.!page(s) 3[6] Gerard Jungman et al. Supersymmetric dark matter. Physics Reports, 267(5-6):195 – 373, 1996. ISSN 0370-1573.!page(s) 2[7] E. Klinkby. Personal communication, 2011.!page(s) 18, 19, 26[8] C. Marino. Personal communication, 2011.!page(s) 16[9] S. P. Martin. A supersymmetry primer. arXiv e-print, 1997. URLhttp://arxiv.org/abs/hep-ph/9709356v5.!page(s) 2[10] B. Mills. Personal communication, 2010-2011.!page(s) 6, 18, 21, 23, 24, 25, 3132[11] M. Spira et al. Higgs boson production at the lhc. Nuclear Physics B, 453(1-2):17 – 82, 1995. ISSN 0550-3213.!page(s) 1[12] The ATLAS Collaboration. The ATLAS TWiki, 2011. URLhttps://twiki.cern.ch/twiki/bin/view/Atlas/WebHome.!page(s) 18, 26, 28[13] The ATLAS TRT collaboration et al. The atlas trt barrel detector. Journal ofInstrumentation, 3(02):P02014, 2008.!page(s) 6[14] A. Wildauer. Personal communication, 2011.!page(s) 2833Appendix ACodeA.1 LowBetaAlg.h (Wrappers Header)This is the header file that contains all of the methods used in the main LowBe-taAlg routines, as well as all of the wrapper methods. The wrapper methods are allat the bottom of the file, under “private”./ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / // / LowBetaAlg .h, (c) ATLAS Detector software/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / // class LowBetaAlgLowBetaAlg is an algoirthm for the identification of Charged StableMassive Particles based on tracking information mainly from the TRT.Timing information and energy deposition are used to indentifycandidate tracks and make measurement of beta and excess ionizationcomparing to r e l a t i v i s t i c particles .author Christopher . Marino <Christopher .Marino@cern.ch> /#ifndef LOWBETAALG H#define LOWBETAALG H#include ”AthenaBaseComps/ AthAlgorithm .h”#include ” TRT ConditionsServices / ITRT CalDbSvc .h”/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /34class AtlasDetectorID ;class Identifier ;class TRT ID;class IMagFieldAthenaSvc ;class TrtToolUBC ;/ / Predeclare histogram classes that you use.namespace InDetDDf class TRT DetectorManager ; gnamespace Trk fclass Track;gnamespace Rec f class TrackParticleContainer ;class TrackParticle ; gnamespace InDetfclass LowBetaAlg : public AthAlgorithm fpublic :LowBetaAlg (const std : : string& name, ISvcLocator pSvcLocator );StatusCode i n i t i a l i z e ( ) ;StatusCode execute ( ) ;StatusCode finalize ( ) ;std : : vector<float> ChargedSMPindicators (const Trk : : Track& track );protected :const TRT ID m trtId ; / / TRT ID helperconst InDetDD : : TRT DetectorManager m TRTdetMgr; / / TRT detector manager ( to get ID helper )unsigned int m minTRThits ; / / Minimum number of TRT hits to give PID.float m RcorrZero ; / / Inputs for R Correctionfloat m RcorrOne; / / Inputs for R Correctionfloat m RcorrTwo; / / Inputs for R Correctionfloat m TimingOffset ; / / timing offset for trailing bit time35/ / std : : string m tracksName; //!< Name of track container in StoreGatestd : : string m trackParticleCollection ; / / !< Name of track container in StoreGatestd : : string m InDetLowBetaOutputName; / / !< Name of output container to store results/  trying to get ahold of the TRT calib DB:  /ServiceHandle<ITRT CalDbSvc> m trtconddbsvc ;ServiceHandle<IMagFieldAthenaSvc> p MagFieldAthenaSvc ;private : / / Functions / variables for using TrtToolsUBC , see TrtToolsWrapper . cxx/ / / / / / / / / // / / / / / / / / / Member variables needed for TrtToolUBC to function properly/ / / / / / / / / // / The actual TrtToolUBC class instance ( all the rest here is the wrapper)TrtToolUBC m TrtTool ;/ / boolean value that specifies whether TrtToolUBC was initialized successfullybool m TrtToolInitSuccess ;/ / Track r e f i t containerstd : : string m UnslimmedTracksContainerName ;/ / / / / / / / / // / / / / / / / / / ATHENA function equivalents ( call from corresponding function )/ / / / / / / / / /StatusCode initializeTrtToolUBC ( ) ;int finalizeTrtToolUBC ( ) ;/ / / / / / / / / // / / / / / / / / / Conditions Database interaction functions/ / / / / / / / / // / Function for updating the TRT conditions database entries/ / Adapted from TRT DriftFunctionTool . cxxStatusCode update(IOVSVC CALLBACK ARGS);/ / / / / / / / / // / / / / / / / / / Wrapper functions for calling TrtToolUBC/ / / / / / / / / // / A wrapper intermediary for the TrtToolUBC : : TRT FEbeta function/ / Meant to be called from LowBetaAlg . cxx , via InDet : : LowBetaAlg : : ChargedSMPindicators/ / Returns a vector of results from TRT FEbeta where:/ / vector [0] = LikelihoodBeta/ / vector [1] = LikelihoodErrorstd : : vector<float> callTrtToolUBC (const Trk : : Track& track );36/ / Gather all of the necessary data that the TRT FEbeta function takes as inputs/ / Sets all of the input argumentsStatusCode parseDataForTrtToolUBC(const Trk : : Track& track , std : : vector<int> TRT bitpattern ,std : : vector<int> TRT bec , std : : vector<int> TRT strawlayer , std : : vector<int> TRT layer ,std : : vector<float> TRT t0 , std : : vector<float> TRT R, std : : vector<float> TRT R track ,std : : vector<float> TrackX , std : : vector<float> TrackY , std : : vector<float> TrackZ ,float RecPt , float RecEta );g;g/ / end of namespace#endif / / LOWBETAALG HA.2 TrtToolsWrapper.cxx (Wrappers Body)This file contains all of the wrapper methods discussed in chapter 3, and is thecore part of my project. These methods are the interaction layer that allows Low-BetaAlg, which is an Athena algorithm, and TRTCHAMP, a private algorithm, tocommunicate. The file has been slightly modified to fit onto the page.#include ” InDetLowBetaFinder / LowBetaAlg .h”#include ” InDetLowBetaFinder / TrtToolsUBC .h”/ / Athena Control and Services#include ” GaudiKernel /MsgStream.h”#include ” GaudiKernel / ISvcLocator .h”#include ” StoreGate / StoreGateSvc .h”/ / Track headers#include ” TrkTrack / Track .h”#include ” TrkTrack / TrackCollection .h”#include ” TrkParticleBase / TrackParticleBaseCollection .h”#include ” TrkParticleBase / TrackParticleBase .h”#include ” Particle / TrackParticleContainer .h”#include ” Particle / TrackParticle .h”/ / Other headers#include ”InDetRIO OnTrack / TRT DriftCircleOnTrack .h”#include ”InDetPrepRawData / TRT DriftCircle .h”#include ” InDetIdentifier /TRT ID.h”37/ / Prints the input of TRT FEbeta () to f i l e (hard set )/ / This is a temporary debug method , and may be removed laterint printTrtToolUBCDebugFile ( std : : vector<int> TRT bitpattern ,std : : vector<int> TRT bec , std : : vector<int> TRT strawlayer ,std : : vector<int> TRT layer , std : : vector<float> TRT t0 ,std : : vector<float> TRT R, std : : vector<float> TRT R track ,std : : vector<float> TrackX , std : : vector<float> TrackY ,std : : vector<float> TrackZ , float RecPt , float RecEta );StatusCode InDet : : LowBetaAlg : : initializeTrtToolUBC ()f/ / Declare the track r e f i t containerdeclareProperty ( ” UnslimmedTracksContainer ” ,m UnslimmedTracksContainerName=”CombinedInDetTracks” );/ / Create the TrtToolm TrtTool = new TrtToolUBC ( ) ;/ / Load the default prior valuesm TrtTool >TRT LoadDefaultPriors ( ) ;/ / Register a function for obtaining priors from the TRT conditions databaseconst DataHandle<CondAttrListCollection> collectionHandle ;StatusCode SC = detStore() >regFcn(&InDet : : LowBetaAlg : : update ,this , collectionHandle , ” /TRT/ Calib / MLbetaPriors ” );if (SC. isFailure ())ATH MSG WARNING( ” Callback registration failed for LowBetaAlg  priors . ” +” Using default prior values . ” );elseATH MSG INFO( ” Registered callback for updating LowBetaAlg  priors ” );return StatusCode : :SUCCESS;gint InDet : : LowBetaAlg : : finalizeTrtToolUBC ()f/ / Done with the TrtTooldelete m TrtTool ;return 0;g38/ / Function for updating the TRT conditions database entries/ / Adapted from TRT DriftFunctionTool . cxxStatusCode InDet : : LowBetaAlg : : update(IOVSVC CALLBACK ARGS P( I , keys ))fconst bool doDebug = false ; / / set to true to print to f i l e belowconst char DEBUGFILE C = ” / afs / cern .ch/ user /s/sschramm/ testarea /16.0.2/ +” InnerDetector / InDetRecAlgs / InDetLowBetaFinder / debugPriors . out ” ;FILE dFile = NULL;ATH MSG INFO( ” Updating priors for the LowBetaAlg likelihood beta estimator ” );/ / Callback function to update priors when condDB data changes :for ( std : : list<std : : string >:: const iterator key=keys . begin ( ) ;key != keys .end ( ) ; ++key)ATH MSG DEBUG( ”IOVCALLBACK for key ” <<  key << ” number ” << I );/ / Read the priorsconst CondAttrListCollection collection ;StatusCode SC = detStore() >retrieve ( collection , ” /TRT/ Calib / MLbetaPriors ” );i f (SC. isFailure () jj collection == 0)fATH MSG ERROR( ”A problem occurred while reading a conditions database object . ” );return StatusCode : :FAILURE;gelse / / Successfully retrievedf/ / Ensure that the collection is the same size as the priors/ / (Make sure we ’ re replacing everything , not just a portion of the priors )i f ( collection >size () != m TrtTool >TRT NumPriors ())ATH MSG WARNING( ”Unexpected number of priors retrieved from the condDB ” +” ( got ” << collection >size () << ” , expected ” <<m TrtTool >TRT NumPriors () << ” ). Using defaults . ” );elsef/ / I f debugging , open the output f i l e and print the headeri f (doDebug)dFile = fopen (DEBUGFILE C, ”w” );i f ( dFile != NULL)fp ri ntf ( dFile , ”#####nn##### prior [ etaIndex ] [ barrelOrEndcap ] ” +” [ radiusIndex ]nn#####nnnn” );int channel ;char name[25];double bitValues ;/ / Loop over the changesfor ( CondAttrListCollection : : const iterator iter = collection >begin ( ) ;39iter != collection >end ( ) ; ++ iter )fchannel = abs( iter >f i r s t );/ / channel will be in one of two forms/ / i f channel >= 100000:/ / channel is in the form 1AABCC (each one is a single base 10 digit )/ / AA = eta bin index (0 to 99) [ ” i ” in TRT LoadPriors ]/ / B = straw type , barrel (0) or endcap(1) [ ”k” in TRT LoadPriors ]/ / CC = radius bin index (0 to 99) [ ” l ” in TRT LoadPriors ]/ / else i f 0 <= channel < 100000:/ / channel is in the form ABC (each one is a single base 10 digit )/ / A = eta bin index (0 to 9) [ ” i ” in TRT LoadPriors ]/ / B = straw type , barrel (0) or endcap(1) [ ”k” in TRT LoadPriors ]/ / C = radius bin index (0 to 9) [ ” l ” in TRT LoadPriors ]int etaIndex ;int barrelOrEndcap ;int radiusIndex ;i f ( channel >= 100000)fchannel  = 100000;etaIndex = channel/1000;barrelOrEndcap = ( channel%1000)/100;radiusIndex = channel%100;gelsefetaIndex = channel /100;barrelOrEndcap = ( channel%100)/10;radiusIndex = channel%10;gi f ( ( etaIndex >= 0 && etaIndex <= TrtToolUBC : :NETABINS)&& ( barrelOrEndcap == 0 jj barrelOrEndcap == 1)&& ( radiusIndex >= 0 && radiusIndex <= TrtToolUBC : :NRFEBINS) )fconst coral : : AttributeList &l i s t = iter >second ;bitValues = ( double )malloc ( sizeof ( double ) 24);for ( int i = 0; i < 24; i ++)fsprintf (name, ” TRT bit %d” , i );bitValues [ i ] = l i s t [name] . data<double>();/ / I f debug , print to f i l ei f ( dFile != NULL)fp ri ntf ( dFile , ” prior[%d][%d][%d ] [ TRT bit %d] = %10fnn” ,etaIndex ,barrelOrEndcap , radiusIndex , i , l i s t [name] . data<double >());40g/ / I f debug , print a new line to f i l ei f ( dFile != NULL)fp ri ntf ( dFile , ”nn” );m TrtTool >TRT UpdatePriorValues ( radiusIndex , etaIndex ,barrelOrEndcap , bitValues );free ( bitValues );gelse i f ( dFile != NULL) / / I f debug , print a warning line to f i l efp ri ntf ( dFile , ”Unexpected result ! Got channel of %d ( eta=%d, ” +”BoE=%d, rad=%d)nnnn” ,channel , etaIndex , barrelOrEndcap , radiusIndex );/ / I f debug , close the file , as we ’ re done nowi f ( dFile != NULL)fclose ( dFile );gggreturn StatusCode : :SUCCESS;g/ / A wrapper intermediary for the TrtToolUBC : : TRT FEbeta function/ / Meant to be called from LowBetaAlg . cxx , via InDet : : LowBetaAlg : : ChargedSMPindicators/ / Returns a vector of results from TRT FEbeta where:/ / vector [0] = LikelihoodBeta/ / vector [1] = LikelihoodErrorstd : : vector<float> InDet : : LowBetaAlg : : callTrtToolUBC ( const Trk : : Track& track )f/ / Return variablestd : : vector<float> LikelihoodValues ;/ / Variables to be determined before calling TRT FEbeta/ /Raw bitpatternstd : : vector<int> TRT bitpattern ;/ / Barrel or endcap indexstd : : vector<int> TRT bec;/ / Strawlayer indexstd : : vector<int> TRT strawlayer ;/ / Layer indexstd : : vector<int> TRT layer ;/ / t0 valuesstd : : vector<float> TRT t0 ;/ / Drift circle radiusstd : : vector<float> TRT R;/ / Local track radius41std : : vector<float> TRT R track ;/ / x position of the hitstd : : vector<float> TrackX ;/ / y position of the hitstd : : vector<float> TrackY ;/ / z position of the hitstd : : vector<float> TrackZ ;/ / ptfloat RecPt;/ / etafloat RecEta;/ / Load the priors from a f i l e instead of using the conditions db or the defaults/ / const std : : string fileName = ” / afs / cern .ch/ user /s/sschramm/ testarea /16.0.2/ ” +/ / ” InnerDetector / InDetRecAlgs / InDetLowBetaFinder / ” +/ / ” InDetLowBetaFinder / TRTpriors .MC. root ” ;/ / m TrtTool >TRT LoadPriors ( fileName );/ / Gather / parse all of the neccessary dataStatusCode SC = parseDataForTrtToolUBC( track ,&TRT bitpattern ,&TRT bec ,&TRT strawlayer ,&TRT layer ,&TRT t0,&TRT R,&TRT R track ,&TrackX,&TrackY,&TrackZ,&RecPt,&RecEta );i f (SC. isFailure ())fLikelihoodValues . clear ( ) ;LikelihoodValues . push back( 997);LikelihoodValues . push back( 997);return LikelihoodValues ;g/ / We now have everything we need/ / Create the debug f i l e/ / printTrtToolUBCDebugFile ( TRT bitpattern ,TRT bec , TRT strawlayer , TRT layer ,/ / TRT t0 ,TRT R, TRT R track , TrackX , TrackY , TrackZ ,RecPt ,RecEta );/ / Now call the actual function we wantLikelihoodValues = m TrtTool >TRT FEbeta( TRT bitpattern ,TRT bec ,TRT strawlayer , TRT layer , TRT t0 ,TRT R, TRT R track ,TrackX , TrackY , TrackZ ,RecPt ,RecEta );return LikelihoodValues ;g42/ / Gather all of the necessary data that the TRT FEbeta function takes as inputs/ / Sets all of the input argumentsStatusCode InDet : : LowBetaAlg : : parseDataForTrtToolUBC( const Trk : : Track& track ,std : : vector<int> TRT bitpattern , std : : vector<int> TRT bec ,std : : vector<int> TRT strawlayer , std : : vector<int> TRT layer ,std : : vector<float> TRT t0 , std : : vector<float> TRT R,std : : vector<float> TRT R track , std : : vector<float> TrackX ,std : : vector<float> TrackY , std : : vector<float> TrackZ ,float RecPt , float RecEta)f/ / Variable for non r e f i t d r i f t circles , to be used as a checkstd : : vector<float> TRT R notFit ;/ / Clear all the vectorsTRT bitpattern >clear ( ) ;TRT bec >clear ( ) ;TRT strawlayer >clear ( ) ;TRT layer >clear ( ) ;TRT t0 >clear ( ) ;TRT R >clear ( ) ;TRT R track >clear ( ) ;TrackX >clear ( ) ;TrackY >clear ( ) ;TrackZ >clear ( ) ;TRT R notFit . clear ( ) ;/ / Get the non r e f i t track particle d r i f t circle radii for checking/ / our refits laterconst DataVector<const Trk : : TrackStateOnSurface> hits =track . trackStateOnSurfaces ( ) ;i f ( hits )f/ / Loop over the hitsDataVector<const Trk : : TrackStateOnSurface>:: const iterator hitIterEnd =hits >end ( ) ;DataVector<const Trk : : TrackStateOnSurface>:: const iterator hi tI ter =hits >begin ( ) ;for (; h itI ter != hitIterEnd ; ++ h itI te r )f/ / only include this hit i f we can call a TRT d r i f t circle out of a/ / measurementBase object based on i tconst Trk : : MeasurementBase  measurement = ( hi tI ter) >measurementOnTrack ( ) ;43i f (measurement)f/ / Get d r i f t circle ( ensures that hit is from TRT)const InDet : : TRT DriftCircleOnTrack  driftCircle =dynamic cast<const InDet : : TRT DriftCircleOnTrack >(measurement );i f ( driftCircle )f/ / Check the raw datai f ( driftCircle >prepRawData ())ffloat driftCircleRadius =  999;driftCircleRadius = driftCircle >localParameters ( ) [ Trk : : driftRadius ] ;TRT R notFit . push back( driftCircleRadius );ggggg/ / Determine pt , eta , phi/ / Perigee exists i f we got here (checked for in/ / InDet : : LowBetaAlg : : ChargedSMPindicators )const Trk : : TrackParameters perigee = track . perigeeParameters ( ) ;const HepVector& parameterVector = perigee >parameters ( ) ;double qOverP = parameterVector [ Trk : : qOverP ] ;double theta = parameterVector [ Trk : : theta ] ;double phi0 = parameterVector [ Trk : : phi0 ] ;i f ( tan ( theta /2.0) < 0.0001)fATH MSG DEBUG( ”TrtToolUBC aborting due to theta value ( tan ( theta /2) < 0.0001” );return StatusCode : :FAILURE;gdouble eta =  log ( tan ( theta /2.0));i f (qOverP == 0.0)fATH MSG DEBUG( ”TrtToolUBC aborting due to momentum value (q/p == 0) ” );return StatusCode : :FAILURE;gdouble pt = fabs (1.0/qOverP) sin ( theta );/ / Set pt and eta RecPt = pt ; RecEta = eta ;44/ / Check i f the track r e f i t container is in storegatei f (! evtStore() >contains<TrackCollection>(m UnslimmedTracksContainerName ))f/ / Warn the user that the algorithm failedATH MSG WARNING( ” StoreGate does not contain the CombinedInDetTracks container ” );return StatusCode : :FAILURE;g/ / Get the track r e f i t container from storegate/ / (We’ve already checked that i t ’s there )const TrackCollection unslimmedTracks (0);StatusCode SC = evtStore() >retrieve (unslimmedTracks , m UnslimmedTracksContainerName );i f (SC. isFailure () jj ! unslimmedTracks)fATH MSG WARNING( ”Could not retrieve CombinedInDetTracks container ” );return StatusCode : :FAILURE;g/ / need to loop over r e f i t container to find the right r e f i t track ,/ / NOT 1:1 with track particles !float refitEta =  999;float refitPhi =  999;float etaphiCone = 0;float bestCone = 9999;TrackCollection : : const iterator MATCH = unslimmedTracks >begin ( ) ;for ( TrackCollection : : const iterator ITR = unslimmedTracks >begin ( ) ;ITR!=unslimmedTracks >end ( ) ; ++ITR)fconst Trk : : MeasuredPerigee  aMeasPer =dynamic cast<const Trk : : MeasuredPerigee >(( ITR) >perigeeParameters () );etaphiCone = sqrt (pow(  log ( tan (aMeasPer >parameters ( ) [ Trk : : theta ]/2)) eta , 2) + pow( aMeasPer >parameters ( ) [ Trk : : phi0 ]  phi0 ,2));i f ( etaphiCone < bestCone )fbestCone = etaphiCone ;refitEta =  log ( tan (aMeasPer >parameters ( ) [ Trk : : theta ] / 2 ) ) ;refitPhi = aMeasPer >parameters ( ) [ Trk : : phi0 ] ;MATCH = ITR;gg45/ / Check for r e f i t hits (aka track states on surfaces , tsos )const DataVector<const Trk : : TrackStateOnSurface> refitHits =dynamic cast<const DataVector<const Trk : : TrackStateOnSurface> >(( MATCH) >trackStateOnSurfaces ( ) ) ;i f ( refitHits )fDataVector<const Trk : : TrackStateOnSurface>:: const iteratorhitIterEnd = refitHits >end ( ) ;DataVector<const Trk : : TrackStateOnSurface>:: const iteratorhi tI ter = refitHits >begin ( ) ;/ / Loop over hitsfor (; h itI ter != hitIterEnd ; ++ h itI te r )f/ / only include this hit i f we can call a TRT d r i f t circle out of a/ / measurementBase object based on i tconst Trk : : MeasurementBase  measurement = ( hi tI ter) >measurementOnTrack ( ) ;i f (measurement)f/ / Get d r i f t circle ( ensures that hit is from TRT):const InDet : : TRT DriftCircleOnTrack  driftCircle =dynamic cast<const InDet : : TRT DriftCircleOnTrack >(measurement );i f ( driftCircle )f/ / Check the raw datai f ( driftCircle >prepRawData ())f/ / Raw bit patternTRT bitpattern >push back( driftCircle >prepRawData() >getWord ( ) ) ;/ / TRT ID informationIdentifier DCoTId = driftCircle >identify ( ) ;int bec = m trtId >barrel ec (DCoTId );int strawLayer = m trtId >straw layer (DCoTId );int layer = m trtId >layer or wheel (DCoTId );TRT bec >push back(bec );TRT strawlayer >push back( strawLayer );TRT layer >push back( layer );/ / Get TRT calibration from the database , t0Identifier TRTlocal = m trtId >straw id (bec ,m trtId >phi module (DCoTId) , layer ,strawLayer , m trtId >straw (DCoTId ) ) ;double t0 = m trtconddbsvc >getT0( TRTlocal );TRT t0 >push back( t0 );/ / Get d r i f t cirlce radiusfloat driftCircleRadius =  999;46driftCircleRadius = driftCircle >localParameters ( ) [ Trk : : driftRadius ] ;TRT R >push back( driftCircleRadius );/ / Get local track radius ( track anode distance )const Trk : : TrackParameters hitParam=(( hi tI ter) >trackParameters ( ) ) ;float localTrackRadius =  999;i f ( hitParam )localTrackRadius = hitParam >parameters ( ) [ Trk : : driftRadius ] ;TRT R track >push back( localTrackRadius );/ / Get the x , y , and z positions of the hitTrackX >push back( driftCircle >globalPosition ( ) . x ( ) ) ;TrackY >push back( driftCircle >globalPosition ( ) . y ( ) ) ;TrackZ >push back( driftCircle >globalPosition ( ) . z ( ) ) ;ggggg/ / Compare the non r e f i t and r e f i t d r i f t circle radiii f ( TRT R notFit . size () != TRT R >size ())bestCone = 9999;elsefor ( unsigned int i = 0; i < TRT R >size ( ) ; i ++)i f (( TRT R)[ i ] != TRT R notFit [ i ])bestCone = 9998;return StatusCode : :SUCCESS;g47/ / Prints the input of TRT FEbeta () to f i l e (hard set )/ / This is a temporary debug method , and may be removed laterint printTrtToolUBCDebugFile ( std : : vector<int> TRT bitpattern ,std : : vector<int> TRT bec , std : : vector<int> TRT strawlayer ,std : : vector<int> TRT layer , std : : vector<float> TRT t0 ,std : : vector<float> TRT R, std : : vector<float> TRT R track ,std : : vector<float> TrackX , std : : vector<float> TrackY ,std : : vector<float> TrackZ , float RecPt , float RecEta)fstatic int trackNum = 1;const char FILENAME C = ” / afs / cern .ch/ user /s/sschramm/ testarea /16.0.2/ ” +” InnerDetector / InDetRecAlgs / InDetLowBetaFinder / debugFile . out ” ;FILE outFile ;unsigned int i ;i f (trackNum == 1)outFile = fopen (FILENAME C, ”w” );elseoutFile = fopen (FILENAME C, ”a” );i f ( outFile == NULL)return  1;fp ri ntf ( outFile , ”#nn#Track Number %dnn#RecPt = %f , RecEta = %fnn#nn” ,trackNum++,RecPt ,RecEta );fp rin tf ( outFile , ”%%Start TRT bitpattern :nn” );for ( i = 0; i < TRT bitpattern . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%dnn” , TRT bitpattern [ i ] ) ;fp ri ntf ( outFile , ”%%End TRT bitpattern :nn” );fp ri ntf ( outFile , ”%%Start TRT bec:nn” );for ( i = 0; i < TRT bec. size ( ) ; i ++)fp ri ntf ( outFile , ”nt%dnn” ,TRT bec[ i ] ) ;fp ri ntf ( outFile , ”%%End TRT bec:nn” );fp ri ntf ( outFile , ”%%Start TRT strawlayer :nn” );for ( i = 0; i < TRT strawlayer . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%dnn” ,TRT strawlayer [ i ] ) ;fp ri ntf ( outFile , ”%%End TRT strawlayer :nn” );fp ri ntf ( outFile , ”%%Start TRT layer:nn” );for ( i = 0; i < TRT layer . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%dnn” ,TRT layer [ i ] ) ;fp ri ntf ( outFile , ”%%End TRT layer:nn” );fp ri ntf ( outFile , ”%%Start TRT t0:nn” );48for ( i = 0; i < TRT t0 . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TRT t0 [ i ] ) ;fp ri ntf ( outFile , ”%%End TRT t0:nn” );fp ri ntf ( outFile , ”%%Start TRT R:nn” );for ( i = 0; i < TRT R. size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TRT R[ i ] ) ;fp ri ntf ( outFile , ”%%End TRT R:nn” );fp ri ntf ( outFile , ”%%Start TRT R track:nn” );for ( i = 0; i < TRT R track . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TRT R track [ i ] ) ;fp ri ntf ( outFile , ”%%End TRT R track:nn” );fp ri ntf ( outFile , ”%%Start TrackX:nn” );for ( i = 0; i < TrackX . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TrackX [ i ] ) ;fp ri ntf ( outFile , ”%%End TrackX:nn” );fp ri ntf ( outFile , ”%%Start TrackY:nn” );for ( i = 0; i < TrackY . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TrackY [ i ] ) ;fp ri ntf ( outFile , ”%%End TrackY:nn” );fp ri ntf ( outFile , ”%%Start TrackZ:nn” );for ( i = 0; i < TrackZ . size ( ) ; i ++)fp ri ntf ( outFile , ”nt%fnn” ,TrackZ [ i ] ) ;fp ri ntf ( outFile , ”%%End TrackZ:nn” );fclose ( outFile );return 0;g49


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items