Studies on tracking for t ID

Generator level:

This plot shows the fraction of track lost when a pT , D f and D h cuts are applied.

I've used a Pythia Z -> t t file and used pions and Kaons from the t decay. No distinction between 1 prong and 3 prong decays. For D f and D h I took the difference between the pion/Kaon and the t .

 

 Gtr Tuple stuff:

At first plots about tracking efficiency of muons and pions, both at 50 GeV and 5 GeV to see if the efficiency for lower momentum particles is much lower. It turned out that the efficiency for pions is only about 70% even for central tracks while the efficiency for muons is in the high 90s. Z -> t t and W -> t n refer to DÆ GSTAR files (each with 500 events)

For the next plots I've been using DÆ GSTAR Z -> t t and W -> t n files (one with 500 events). D f and D h are now the difference between the direction of the calorimeter cluster and the track. The plots show all the tracks (as I used GtrTuple which does not distinguish between different particle, it just keeps tracks).

The last file shows the number of found t in Z -> t t files (500 events) for different cuts applied in reco. The first plot shows the (lack of) gain in number of ts for using MS in track-finding. The pT cut for the next plot was 1 GeV. One gains about 3% if cutting @ 0.4 instead of 0.2. The gain with not applying any pT cut is about 1%, if one would use a cut of 5 GeV one would loose about 11% of ts.

October 27, 1999:

Current status:

Available:

- number of prongs, pt, eta, phi for first 3 prongs

- can match with reco track (as before) and McTrack

I ran over the Single tau files (40 and 10 GeV), there was no McKineChunk , so no information about the prongs.

Of all MCC Phase 2 Z -> t t just one phythia 200 event file did not crash on the attempt to make McTracks, this was used for the Z -> t t plots.

 The single tau plots are made with default cuts to get the tau candidates, no tracks are required. The number of tracks if "notracking" is explicitly mentioned is set to 1 be default. The matching is done with McTracks and reco (Gtracks).

The Z -> t t plots are made with default cuts as well, and here as well no tracks are required. The second page shows the distance between the tau cluster (tau candidate) and the tau parton. The distance plotted is sqrt(D f **2+ and D h **2). The prongs are the daughters of that parton. The plots should just illustrate that there is a connection between the prongs and the taus

The last plot shows which tracks are lost. These are 1 prong ts , the black histogram are the parameters of the one prong track, the blue and read one are the one prong t tracks which are not found (not matched to the t cluster).

November 10, 1999:

These plots show basically the same as the October ones, just with an updated tracking version and a try to use root instead of paw.

Here are the single tau plots and here the Z -> t t plots.

In this the plot is shown which 1 prong tau are lost if a track is required. The black histogram shows the 1 prongs, shown in blue and red are the 1 prongs which are still found if a match with a McTrack/GTrack is required.

The main reason for the loss of tau candidates if a track is required seems to be the fact that the tracking works only in the central region yet. The efficiency at least for the 1 prong taus in the central region is about 90% and using McTracks does not bring any considerable gain. That means that the tracking efficiency itself does not "harm" the tau finding in the central region.

February 2, 2000:

Verification of preco03.05:

First I've been running over the officially reco'ed 1.1 minbias Z -> t t and minbias W -> t files. I matched the tau candidates with Gtracks and McTracks. The first page of both plots shows the number of taus and tracks for

1) no required track

2) match with McTrack required

3) match with Gtrack required

In the case of the official reco files a match with a Charged particle was required before a tau candidate was accepted, thus the numbers of 1) and 3) should be equal.

The second page show pt and eta of the taus found with Gtracks and McTrack match (Gtrack: red, McTrack blue). The Gtrack curve exceeding the McTrack curve shows that fake tracks lead to keeping of too many tau candidates which is veven worse when there are too many tau candidates in the first place as it seems to be that case for this reco version. This can be seen in the following plots.

For all following plots I've been using pmc02.01 MC files and and reco'ed myself with the "default" d0reco, except that I didn't require a track for tau candidates. Thus the plots with no track requirement have a meaning.

At first the single tau files where everything looks fine. No difference between tau and taubars, so I'm only showing the plots for 10 GeV and 40 GeV single taus. For the number of taus on the right sides, the black line are all with matched tracks (for 2) and 3) ), the red lines are the tau candidates with not more that 5 tracks. I've been using a wider match window in for this file, a 0.4 delta phi and 0.4 delta eta was required instead of the default 0.2. After a match with a track, the numbers look fine, it is just a bit strange that there are events with more than one tau candidate in this kind of "event".

For the last plots I've been using a Z -> t t file with 0 minbias.