Re: Note on tracking-efficiency, TPM1

From: Peter H. L. Christiansen (pchristi@nbi.dk)
Date: Mon Oct 02 2000 - 09:05:06 EDT

  • Next message: Peter H. L. Christiansen: "BRAT-1-11-1"

    Hello Norway
    
    A very nice note. 
    
    A few comments :
    1) I don't understand what you say on page 1. You substitute the geant hit
    with ...
    
    2) What is the efficiency vs the number of initial tracks ?
    
    3) Do you check to see if you find the track alone with the tracking code.
    The reason for not reconstructing some of the geant tracks is that some of
    them are quite curved. Print out the chi**2 and compare to when you find
    the track.
    In general the Chi**2 output from at least the BrTrackFollowFinder looks
    bad( I included this as a new histo in BrClusterFinderBase) and is of
    course quite interesting for the quality of tracks we
    find. Does it look consistently bad for the StringFinder ?
    This is of course related to what we assume the white noise to be (
    currently 2 adc channels ).
    
    4) Are the 2 trackers allowed to miss the same number of planes, ghost
    hits share the same number of hits etc. ? What trigger do you use - I
    would start with trigger 6 where we know that there are much less banana
    tracks. Cuts on vertex ?
    
    5) I think the problem with anti-ghost hits is related to the break down
    of the tracking code at least for -2 and down. Now I propogate the status
    to the Entry function and store it in a histo ( 0 = ok, 1 = failed ), but
    maybe you want to make the status an accessible parameter. At least I
    think the crashes should be seperated for both trackers, so we only get
    the relative tracking efficiency and then seperately the crash
    efficiency;)
    
    6) I don't understand why the distribution in figure 1 has such a long
    tail for the TrackStringFinder. 
    
    7) I think that instead of using to much time on going down to the
    TPCSequence level it would be interesting to focus on why we don't find
    the tracks. This is of course a damn hard task, but maybe there is a
    simple subset of events that could be viewed on a monitor that would shead
    some light on this. One could also carefully keep track of the tracks
    before and after and compare them, compare tracks from the 2 methods and
    compare tracks in a single ouput to see how the general overlap
    distribution looks.
    
    I will try to look at the trackfollowfinder in the coming week.
    
    Cheers,
       Peter
    
    :-) --------------------------------- )-:
    |Peter H L Christiansen aka PAN @ NBI	|
    |EMAIL  : pchristi@nbi.dk		|
    |OFFICE : Tb1 @ NBI			|
    |PHONE  : 353 25269 <- New!!		|
    |SNAIL  : Sdr. Fasanvej 14 ST 2000 F	|
    |PHONE  : 38 872042 			|
    :-D --------------------------------- \-:
    



    This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 09:15:32 EDT