A new algorithm is described for the track recognition in PHENIX muon
identifier. The track, called road in muon identifier, finding efficiency is
shown as a function of muon momentum by using single muon events.
1 Introduction
In current PHENIX muon off-line software, the reconstruction
chain starts from finding
roads in muon identifier first. With Kyle Pope's remarkable effort,
an integrated muon
identifier off-line software[1] has been established and has been used
for various studies,
such as Mock Data Challenge II (MDC2). During the study for the beam
shielding for south
muon arm[2], an inefficiency of muon tracks appeared when tube occupancy
went high. On
the other hand, the requirement for an initial road, both a horizontal
and a vertical twopack
fired in gap 2 and gap 3, in current algorithm will immediately loss
12% of muon tracks if
a 97% detection efficiency is expected for each twopack(Table 1). These
drive us to find a better
algorithm for the muon identifier road finder and this documentation
summarizes the
study on a possible alternative approach.
2 The Algorithm for the New Road Finder
Before going to the algorithm, let's consider what
requirements we expect to a road
finder. Here is a list which are basic requirements to the muon track(road)
reconstruction.
a. High reconstruction efficiency for muon tracks in the Muon IDIn item (a), high efficiency means a reasonable and then acceptable reconstruction efficiency
b. Good road quality for muon roads
c. Less number of ghost roads
d. Tell difference between muon and hadron tracks
which may be affected by detector efficiency and the multiplicity of a event. A good road quality
is required for a better match with the tracks found in Muon Tracker, especially when in
high multiplicity case in central Au-Au collision. Previous study has shown that the direction
of a muon road found by current road finder has a significant change when it is mixed with
a central Au-Au event. This is one reason to loss reconstruction efficiency in mixed event
case. A ghost road is a reconstructed road which doesn't associate with any physical tracks
in Muon ID. Obviously, less the number of ghost roads, better the road finder. Although reject
hadron is not the basic assignment to a road finder, it is critical that road finder should provide
all possible information recorded by muon identifier. The parameters which are to be used
for discriminate analysis should be considered in road finder algorithm.
The starting point of the new algorithm is to use
raw hits, instead of clusters, and two single
start gaps to generate one dimensional seed roads (separate horizontal
and vertical orientation),
instead of two start gaps together to form two dimensional seed roads
(horizontal and vertical
orientation together). By using raw hits, we may achieve the maximum
spatial resolution, limited
by the width of twopack in muon identifier, and then a better muon
road quality in high multiplicity.
The advantage to use two single gaps to generate one dimensional seed
roads is we only loss few
percent of muon tracks when we apply a realistic detection efficiency
to the muon identifier(Table 1).
The disadvantage to do so is there will be more ghost roads. The method
applied to reduce the
number of ghost roads will be discussed in section 5 in this document.
The new algorithm can be described as follows:
1. Form an one dimensional road seed from each combination of vertex point and vertical
twopacks in each panels of the first seed plane.2. Determine the road trajectory by fitting a straight line to the position of the twopacks.
3. For each of the planes except the seed plane in the same muon arm,
4. Apply road quality cut to eliminate ghost roads.
- project along the straight line trajectory to the plane, and determine the
position of the intersection point of the line with the plane- search for vertical twopacks whose positions are within a specific distance
from the intersection point. First search in the panel with the same number
as the one from which the seed twopack was taken, then in other panels if
there is no vertical twopack to have been found .- If there are twopacks within the search window, attach the one with position
closest the intersection point.- refit the trajectory including newly attached twopack.
5. Check if there exists a duplicate road and save one-dimensional road if the answer is no.minimum number of gaps with a fired twopack vertex cut c2 cut 6. Apply step 1 through step 5 for second seed plane.
7. Apply step 1 through step 6 for horizontal twopacks.
8. Form two-dimensional roads with found vertical roads and horizontal roads. For each of
the combination of a vertical road and a horizontal road,the difference of last plane of the vertical road and the horizontal road should be
less than or equal 1.in each gap, the twopack in the vertical road and the twopack in the horizontal
road should have same panel number or their intersection is in a panel overlap
region if the overlap exists.if satisfy above two condition, calculate two-dimensional road quality with all
twopacks associated to the vertical and horizontal road.apply last plane cut, vertex cut and c2 cut to the two-dimensional road
3 Road Quality
Road quality check is an important procedure to eliminate
background roads. To 1D roads,
a vertex cut is the primary means and the c2
cut is left open as described in [1]. Except that, we require
that a road should contain at least two gaps with a fired twopack.
To 2D roads, an x-y consistency
check is the main means to reject background road, i.e., both horizontal
road and vertical road have
a similar depth and there physically exists the intersection of a horizontal
twopack and a vertical twopack
in each gap.
4 Road Finding Efficiency
Road finding efficiency is a very important parameter
to evaluate a road finder's power. Basically,
it can be written as,
e = Nfound / Nselect (1)
here Nselect is number of primary tracks selected
from GEANT tracks, Nfound is number of tracks
(among selected tracks) which match the found roads. There has
been a extensive discussion on how to
determine the road finding efficiency, e.g. what is the selection criteria
and what calls a match
between a found road and a primary track. In current muon ID software,
a dominant
contributor method is used[1]. The road finding efficiency determined
by the method highly
depends on the contributor ratio cut, especially when J/Y
events are mixed with central HIJING
Au + Au events.
When refer to road finding efficiency, actually we
have more interesting on muon road finding
efficiency and less interesting on pion road finding. One the other
hand, current GEANT track selection criteria,
in which the track should be original track and it should strike both
horizontal and vertical twopacks in
gap 2 and gap 3 (two seed gaps), doesn't ensure the track is muon.
For muon tracks, a larger ratio
cut should be better. Currently, 60% are applied, it's hard to say
a road with 40% hits from other
tracks can well reconstruct the original track. In contrast,
60% cut might be too large for a pion
road. Therefore, a different definition of (muon) road finding efficiency
is applied in our calculation.
The selected GEANT tracks are those muon tracks which
are from J/Y events, regardless they are
mixed or not with Au + Au HIJING events, and reach gap 3 in muon identifier.
For each selected
GEANT track, check if there exists a road, among roads found by road
finder, which meets the
maximum deviation between the track and the road in the muon identifier
is less than a threshold,
Max{di} < dthreshold (2)
Here di is that deviation between the track and the
road in a gap of the muon identifier dthreshold
is
set to 10cm currently which is about 2/3 of the search window. One
may argue that the deviation at
gap 5 may out of the road if the road was fitted by a straight line
due to the energy loss in absorber
of the muon identifier although there is a good agreement between the
road and the track in gap 1-4.
To avoid affecting road finding efficiency from this, gap 5 is not
included in the calculation of maximum
deviation.
Table 1. Road Finding Efficiency for Single Muons
=========================================================
momentum Twopack New Road Finder Old Road Finder
(GeV/c) Efficiency Nselect Nfound e Nfound e
--------------------------------------------------------------------------------------
2.0 97% 461 330 71.6% 260 56.4%
2.5 97% 993 823 82.8% 730 73.5%
3.0 97% 993 961 96.8% 849 85.5%
5.0 97% 998 976 97.8% 882 88.4%2.0 100% 461 353 76.6% 299 64.8%
2.5 100% 993 861 86.7% 826 83.2%
3.0 100% 993 975 98.2% 966 97.2%
5.0 100% 998 996 99.8% 995 99.7%
========================================================
( This table is obtained with 1000 single muons lunched from (0, 0, 0) with a emission angle 25+-2 degree)
In Table 1, road finding efficiency is calculated
with 1000 single muon events for each
momentum in 2.0-5.0 GeV/c region. As we expected, the efficiency provided
by new road
finder is about 10% better than that by old road finder when detection
efficiency of a twopack
is 97%.
It is also very interesting to see the road finding
efficiency at different hit/tube occupancy.
Central Au + Au central events were mixed with single muons (3GeV/c)
lauched from (0, 0, 0)
with q = 15o, 20o,
25o and 30o ( f = 20o
)
for this purpose. Fig. 1 shows centroid positon of
single muons (marked by red circle) moves from higher background area
to lower background
area as the emission angle is changed from 15o
to 30o . The road finding efficiency for these
mixed events at each angle is calculated by using above method and
is listed in Table 2.
Table 2. Road Finding Efficiency for Single Muon (3GeV/c)
and Mixed Events (Central Au+Au HIJING)
=========================================================
q Occupancy Twopack New Road Finder Old Road Finder
(degree) H V Efficiency Nselect Nfound e Nfound e
--------------------------------------------------------------------------------------
Sinlge muon events
15 100% 394 388 98.5% 385 97.7%
20 100% 399 392 98.2% 393 98.5%
25 100% 398 391 98.2% 390 98.0%
30 100% 395 372 95.0% 372 95.0%
---------------------------------------------------------------------------------------
Mixed events
15 0.37 0.28 100% 394 380 96.4% 333 84.5%
20 0.32 0.17 100% 399 387 97.0% 356 89.2%
25 0.29 0.11 100% 398 384 96.5% 355 89.2%
30 0.22 0.06 100% 395 369 93.4% 349 88.4%
==========================================================
( This table is obtained with 400 single muon events + central AuAu HIJING events)
Comparing road finding efficiencies between single muon evnets and mixed
events, the efficiency
loss in mixed event case (higher tube occupancy) is few percent and
remains almost same.
5 Ghost Roads
It is well understood that a road finder should provide
ghost roads as less as possible if it
is not conflict with other requirements. There are a couple of reasons
to reduce number of ghost
roads: a) increase the analysis speed and save CPU time, b) reduce
the number of ghost tracks
and then depress the software background (for single muon and di-muon).
Ghost road can be
decreased by following measures: i) using a norrow search window, ii)
using a larger threshold
for cluster size, iii) using a narrow vertex cut, iv) using a smaller
chi square cut. All these 4
measures will result in a lower road finding efficiency. The optimization
is neccessary before
using these measures.
It is very interesting that c2
from track fit in muon tracker can be used to throw away most
of the ghost roads. In Fig. 2, the number of found roads and number
of matched tracks are plotted
for 300 J/Y events mixed with central AuAu
HIJING events. Result from a high road finding efficiency,
averagely new algorithm found 25 roads/event. After applying a chi
square cut (40) for matched tracks,
finally the matched tracks are about 3 tracks/event in average. It
seems that 2 road finders might be
a good choice, i.e., the first road finder provide a higher road finding
efficiency but with many
ghost roads and second road finder recalculates roads which matched
with tracks in muon tracker.
Fig. 3 shows the reconstructed invariant mass of dimuons and a clean
J/Y peak appears (300 J/Y
events). Cuts applied in Fig. 3 are c2
cut = 40, vertex cut = 180cm, unlike sign di-muon and
muprob = 1. Comparing Fig. 3(a) and Fig. 3(b), we see that J/Y
events were well reconstructed even
they were mixed with heavy background.
6 Hadron Rejection and Other Road Parameters
In current muon software, particle identification
is not the basic assignment for the road
finder, there is another module is dedicated to tell the probability
a track to be a muon. But
obviously road finder should provide neccessary information which directly
or indirectly tells
the difference between a hadron and a muon. As a result of many previous
studies, few parameters
such as LastPlane ( last gap a road reaches) and MaxHit ( maximum number
of hits in a gap
among five muon ID gaps ) etc. are suggested. Different method may
be applied to these
parameters, for instance, look up table and/or discriminate analysis.
7 Future Work
As of the result from our one-week discussion
in UTK, we agreed to use algorithm described in section
2 for the new road finder. The modifications to it are:
a) Road Fit: c2
weighted function fit instead of equal-weight straight line fit.
weight w = e -sc2 dx
.
dx is the thickness of inner absorber.
Currently, s = 0.
b) Search Window: Steering
window instead of fixed size window
Win = a c2
+ b dx + g Here
a
scales momentum dependence, b
scales multiscattering
dependence and g
is the minimum search width. Currently a
= b
= 0.
c) Multiple Cluster Option: instead
of collecting closest cluster in a gap, now we have more options
i) Make separate roads
ii) Use closest cluster
iii) Merge Clusters
d) All related parameters to control the road finder could be preset within offline framework.
a)-c) have been partially discussed by Vince and Soren before[3]. We
are planning to create a new object
TMui1DRoad and revise the existing TMui2DRoad object. Kyle will
be responsible to the TMui1DRoad and
TMui2Droad classes. Yajun will be responsible to road finder
module which uses the TMui1DRoad and
TMui2DRoad objects.
Reference
[1] Muon Identifier Offline Pattern Recognition Software,
Kyle Pope,
http://www.phenix.bnl.gov/WWW/publish/pope/MuID/muid-algorithms/
[2] Design of Collar for South Muon Identifier of PHENIX Detector,
Yajun Mao, http://www.phenix.bnl.gov/WWW/publish/mao/collar/
[3] Essential Elements of the Muon Identifier Road Finder,
Vince and Soren.
