Jeffery T. Mitchell

1/5/00

Download this document in PDF or Compressed Postscript formats.

The nature of heavy ion collisions at RHIC to deliver high multiplicities of charged particles coupled with the design of the PHENIX magnet and detector lay-out provide a very challenging environment for inter-detector tracking. These factors also contribute to a challenging evaluation problem. This note will focus on one aspect of the evaluation: that of determining the efficiency of associations between reconstructed drift chamber tracks and reconstructed pad chamber clusters.

The evaluations shown were initially performed upon PHENIX software tag phs4/phs5, which is the version used for the first PHENIX publication. However, some lower statistics results on the tag phs10, which is the version used in preparation for the Quark Matter 2001 conference are also shown. Known differences in the two versions are small bug fixes in the drift chamber, track model, and hit association software. The software being evaluated include the drift chamber track reconstruction, pad chamber track reconstruction, the track model, and the global hit association software.

The basis for all evaluations presented in this note is the concept of the dominant contributor for a drift chamber track. The dominant contributor is defined as the GEANT track which contributes the highest number of hits to the reconstructed drift chamber track. Another concept is that of the dominant contributor purity, which is defined as percentage of hits in the reconstructed track which can be traced back to the dominant contributor. Note that it is possible for a dominant contributor purity to be below 50% since a reconstructed track with n hits on it can have up to n contributors to it.

In order to evaluate the pure association efficiency, it is necessary to first eliminate inefficiencies due to the individual detectors themselves or due to reconstruction inefficiencies in the intra-detector software. This is done by following the line of reasoning listed below for each GEANT track being evaluated.

1. Is the drift chamber track reconstructable? For a drift chamber track to be reconstructable, it must have a minimum number of available GEANT hits for reconstruction.
2. Is the pad chamber cluster reconstructable? For a pad chamber cluster to be reconstructable, it must have an available GEANT hit for reconstruction. For example, a track that traverses the gap between pad chamber sectors is considered not to be reconstructable.
3. If a GEANT track is considered to be reconstructable for the drift chamber, was the drift chamber track reconstructed? This is true if a reconstructed track yields a dominant contributor identical to the GEANT track.
4. If a GEANT track is considered to be reconstructable for the pad chamber, was the pad chamber cluster reconstructed? This is true if there is a direct relation between a reconstructed cluster and the GEANT track.
5. A GEANT track will only be evaluated if both the drift chamber track and pad chamber cluster is both reconstructable and reconstructed. If that criteria is passed, then an association has been performed correctly only if the drift chamber dominant contributor is identical to the the GEANT track related to the reconstructed pad chamber cluster, or matched.
6. Individual detector reconstruction efficiencies are calculated by taking the number of reconstructed tracks and dividing them by the number of reconstructable tracks for that detector.
7. Inter-detector association efficiencies are calculated by taking the number of matched reconstructed hits in a global track and dividing them by the number of associable hit pairs, which is defined as having the hits or tracks in both detectors reconstructable.

This evaluation algorithm can easily be extended to include other detectors or more than two detectors.

All software used for this evaluation is in the repository within the cge package. There are two classes described here. The first, called cgeEvalUtils, is a singleton that contains generic GEANT-to-reconstructed track and other evaluation utilities for some subsystems. The second is the specific evaluation class used for this analysis, called cgeEvalTrack.

cgeEvalUtils is a class that contains general utilities that can be used by any evaluator. It is defined as a singleton, much like the PHGeometron in the geo package. The methods used for this evaluation are described below:

• padToGeant: Given a reconstructed pad chamber cluster, this method makes a list of the GEANT hit entries associated with it. This returns the number of valid relations.

• cglPadToGeant: Retrieves a list of the GEANT hits associated to a reconstructed pad chamber cluster associated to a global track. This returns the number of valid associations.

• dchToGeant: For a reconstructed drift chamber hit, this makes a list of GEANT hit entries that are associated with it. This returns the number of valid relations.

• getDomCom: Determines the dominant contributor of a reconstructed drift chamber track. This returns the entry number to the fkin (GEANT track) object for the dominant contributor and the dominant contributor purity. This also works off of global tracks.

• fkinToGeantPad: Given an entry number to the fkin (GEANT track) object, this makes a list of pcghit entries (pad chamber GEANT hits) associated to the GEANT track represented by fkin. This returns the number of relations.

• fkinToGeantDch: Given an entry number to the fkin (GEANT track) object, this makes a list of dcghit entries (associated to the GEANT track represented by fkin).

The specific class used for this evaluation is called cgeEvalTrack. The focus of this class is to calculate the following quantities:

• Drift chamber tracking efficiency

• Drift chamber tracking purity

• Pad chamber reconstruction efficiency

• Drift chamber - to - pad chamber association efficiency

• Momentum resolution

cgeEvalTrack is a GEANT-track-based evaluator. It begins with the set of all GEANT tracks generated in an event by looping over every GEANT track object, fkin. It then queries its input data members to reduce the input set of GEANT tracks to a set to be analyzed for a given evaluation. The efficiency calculations are then only performed on the subset of GEANT tracks that pass all filters. The filters, explained below in the listing of the classes input data members, are designed to provide flexibility for different types of evaluations. For example, the filter can select out only primary particles, or it can be asked to select out only GEANT tracks from a merged event. The specific filters used for this evaluation are described in the next section.

Input data members for the cgeEvalTrack class:

• Verbose: Verbosity level.

• selectMode: GEANT track selection mode.

• geantId: GEANT track id. This is not used if selectMode = 0 or selectMode = 3 If selectMode = 1, this is the GEANT track id in fkin.true_track or the mctrack entry in the GEANT hit. If selectMode = 2, this is the fkin entry number to analyze.

• pidFilter: Particle ID selection flag If this is 0, then all GEANT tracks are analyzed. If this is 1, then only the particle ID in pid is analyzed

• pid: Particle ID. This is only used if pidFilter = 1. If used, this is the GEANT-convention particle ID to analyze

• momFilter: Momentum reconstruction filter flag. If this is 0, then no momentum cut is placed on the GEANT tracks If this is 1, then only GEANT track momenta within the range [minMomentum,maxMomentum] are analyzed.

• minMomentum: Minimum GEANT track momentum range. This is only used if momFilter = 1. The units are GeV/c. Only GEANT tracks between these values will be analyzed.

• maxMomentum: Maximum GEANT track momentum range. This is only used if momFilter = 1. The units are GeV/c. Only GEANT tracks between these values will be analyzed.

• primaryFilter: Particle ancestry filter flag. If this is 0, then all GEANT tracks are analyzed. If this is 1, then only primary GEANT tracks are analyzed. If this is 2, then only secondary GEANT tracks are analyzed.

• armFilter: Arm filter flag. If this is 0, then only arm 0 is analyzed. If this is 1, then only arm 1 is analyzed. If this is 2, both arms are analyzed.

• geantInDch: Drift chamber acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInPc1: PC1 acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInPc2: PC2 acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInPc3: PC3 acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInTec: TEC acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInTof: TOF acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• geantInEmc: EMCAL acceptance filter flag. Setting the flag for this detector requires that a GEANT track have a GEANT hit(s) in the detector for it to be analyzed.

• minDchGeant: Drift chamber hit acceptance filter. If geantInDch is 1, then this is the minimum number of GEANT hits in the drift chamber for a GEANT track to be analyzed.

• minTecGeant: TEC hit acceptance filter. If geantInTEC is 1, then this is the minimum number of GEANT hits in the TEC for a GEANT track to be analyzed.

• minDchRecoHits: The minimum number of GEANT drift chamber hits in a GEANT track for the track to be considered reconstructable for the drift chamber

• evaluateDch: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluatePc1: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluatePc2: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluatePc3: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluateTec: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluateTof: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• evaluateEmc: Evaluation flag. Set the flag for this detector to perform an evaluation on the detector. It will be skipped if the flag is 0.

• minDCPurity: Minimum dominant contributor purity for a correctly reconstructed drift chamber track.

The output of the evaluator comes out in two places. The first is an event-by-event summary of the dominant contributor purity, the drift chamber reconstruction efficiency, the pad chamber reconstruction efficiencies, the drift chamber to pad chamber association efficiencies, and the overall average momentum and p_t resolutions. In addition, ROOT histograms are accumulated over all events for use in the calculation of the following efficiencies as a function of the transverse momentum of the input particle: drift chamber reconstruction efficiency and drift chamber to pad chamber association efficiencies.

The evaluation was performed on HIJING central Au+Au events processed with PISA99. The evaluation was performed for the phs4/5 tag (used for PHENIX's first publication) over 100 events, and for the phs10 tag (used for Quark Matter 2001 presentations) over 50 events. The smaller dataset for phs10 is due to limitations introduced by new memory leak problems in the drift

chamber reconstruction or the track model.

A special reconstruction chain that processed events starting with GEANT all the way through to the DSTs and then to the evaluation without writing out PRDF files was used. The macro set used can be found in the offline/packages/cge/wrk area of the repository with the prefix camTask (for PHENIX history buffs: this is the original camTask macro set). This reconstruction chain performed the simulation and reconstruction steps for the BBC, drift chamber, and pad chambers only. Global hit association is performed only for drift chamber reconstructed tracks to pad chamber reconstructed clusters using the PHDchTrack track model. Following reconstruction, the event method of the cgeEvalTrack class is called to process all GEANT and reconstructed tracks in the event.

The evaluation was set up to only consider primary particles with a total momentum between 0.2 and 5.0 GeV/c, inclusively. GEANT particles must have at least 40 GEANT hits deposited in the drift chamber (traversing all planes) and register a hit in all 3 pad chambers. There is no restriction on the arm number or the particle type.

For the phs10 evaluation, the average efficiencies over all analyzed events were calculated. These results are averaged over all momenta.

• Average number of total input GEANT tracks: 13041
• Average number of GEANT tracks evaluated after all filters were applied: 79
• Average drift chamber dominant contributor purity: 84.4%
• Average drift chamber reconstruction efficiency: 98.5%
• Average PC1, PC2, and PC3 reconstruction efficiency: 93.1%, 93.0%, 89.8%

• Drift chamber to PC1 association efficiency: 93.2%
• Drift chamber to PC2 association efficiency: 84.0% (across the RICH gap)
• Drift chamber to PC3 association efficiency: 81.8%

Below, in Figures 1-6, are the efficiencies as a function of the momentum of the dominant contributor to the global reconstructed track. The error bars are determined by applying binomial distribution statistics to the results. Generally, even across the RICH gap, the hit association efficiency is on the order of 90% for an input momentum above 400 MeV/c. Inside the RICH gap, the efficiencies are very close to 100% for momenta above 400 MeV/c. Almost all inefficiencies can be attributed to inaccurate pointing vectors returned from the drift chamber reconstruction, specifically in the z coordinate.

The momentum resolution plots shown below are obtained by comparing the reconstructed momentum of the global track (in this case, using the drift chamber and PC1 information from the PHDchTrack track model only) to the input GEANT momentum from the dominant contributor. This information is plotted in 200 MeV/c transverse momentum bins in the form:

dp_t/p_t = [p_t(reconstructed) – p_t(GEANT)] / p_t(GEANT)

An example of one of these distributions for the transverse momentum range from 600 MeV/c to 800 MeV/c is shown in Figure 7. The fit in this figure is a Gaussian fit to the entire distribution. These distributions generally have two distinct components, the origin of which is still being investigated. Taking the fits from the entire distribution yield the transverse momentum resolution as a function of p_t shown in Figure 8. The error bars are extracted from the Gaussian fit. However, the peak distribution can be fit instead, as shown in Figure 9. The peak distribution yields the transverse momentum resolution shown in Figure 10. Note that this evaluation calculates not the intrinsic momentum resolution, but the final momentum resolution folding in the detector resolutions, reconstruction inefficiencies, and association efficiencies. The detectors are still simulated without any internal inefficiencies such as dead wires in this evaluation.

A method and the software for evaluating reconstruction and hit association efficiencies has been developed and described here. Results of the evaluation for both the phs4/5 and phs10 software tags show that central arm reconstruction efficiency is performing above 90% for transverse momenta above about 300 MeV/c. In order to optimize momentum resolution, analyses should take care to screen for fully accepted drift chamber tracks. However, there appears to be a low resolution component to the transverse momentum resolution that is not yet understood. This evaluation can be performed to investigate the affect of changes in the software very quickly and easily using the cge package.

The author would like to thank the following PHENIX collaborators for discussions that contributed to this work: Tom Hemmick, Stephen Johnson, Sasha Lebedev, Jerome Lauret, Charlie Maguire, and Dave Morrison.