Quality Checking Tools for the SVT Reconstruction

Diego Zanin and Paola Grosso, Nov 1996

SvtTestTracks is new module added to the package SvtReco which tests the quality of the track finding routines. To work properly it needs first of all the preprocessor flag _MC_TRUTH_ turned on.

CLASSES AND MODULES

  • class SvtGTrack in SvtData. Each SvtGTrack contains a list of SvtGHits having the same GTrack number. A new list has been added to the class AbsEvent so that the list of SvtGTracks belongs to anEvent and must be filled by the module SvtFillGTrack.

    To help separate the detector inefficiency from the track finding one, the class also provides the number of GHits that have produced a digitization both in Z and Phi, that are called DHits. We don't think that, for the time being, there is the needing to make a class "SvtDHit". Being a DHit is a property of GHits that can be easily computed by the list of Digi they have got. In the case of SvtGTracks, their constructor takes care of that computation.

  • abstract class SvtClustGHitMatch in SvtData. It is a prototype as a base class for the classes providing algorithms to associate a Cluster to a GHit. In the view of the creation of test tools for the other detectors it could become of general use, dealing with generalized Clusters and GHits.

  • class SvtClustMatchCalc in SvtData, inherits from the abstract class SvtClustGHitMatch. It implements a function connecting a given cluster to the SvtGHit that most probably generated it. Especially in the view of the implementation of detector imperfections, this class could be the starting point to build also the cluster finding quality checking. At the moment, about 0.3% of the Clusters seem to be the product of a wrong merging, having "purity" around 0.5.
    This class needs the links cluster-to-digis and digis-to-ghits to compute the matching so that the compiling has to be done with the flag _MC_TRUTH_ turned on (see file mc_truth.inc).

  • SvtTestTracks, the module that using all those features associates to each GEANT track a corresponding reconstructed track, finding the imperfections (missing and wrong hits) in the track finding.

    OUTPUT PRODUCED

    It is possible to switch on some flags in the .tcl file to set the kind of output you want when running SvtRecoApp:

  • JobAnalysis: activates a final calculation at the end of the run to get the percentage of perfectly reconstructed tracks, of tracks with 1 missing point on the connected reco track, of tracks with 2 missing points and the percentage of GEANT tracks which have been completely missed and don't have any matching reco track. Furthermore, it reports the percentage of GEANT tracks corresponding to reco tracks having misassociated hits, that is, reco hits associated to other GEANT tracks. Only a selected sample of tracks are considered for the statistics, see the "comments" section below.

  • fillTestHisto activates the filling of two ntuples with the information found: GHitTuple refers to the association between SvtGHits and SvtHitOnTracks, and GTrackTuple is analogously about SvtGTracks and reconstructed tracks;

  • printTestTracks: activates the printing event by event of the results.

    An example of a summary print out for 40 BBbar events follows:

     GEANT tracks:  434
    
     Only GEANT tracks with Dhits in four layers and at most one layer
     with two Dhits enter the sample for statistics
    Sample: 333 (76.73%)
    
     of this sample:
     G tracks perfectly reconstructed  283 (84.98%)
     G tracks with 1 point missing in reconstruction  23 (6.91%)
     G tracks with 2 points missing in reconstruction  12 (3.60%)
     G tracks completely missed 8 (2.40%)
     G tracks associated to R tracks with wrong hits 19 (5.71%)
    

    COMMENTS

    For the time being the quality checking performed by the module SvtTestTracks on the track finding is seriously limited by the lack of information available on the GEANT tracks. The problem is that a track and its "daughters" are labeled by the same GTrack number (variable igtr), so that very often there are tracks that are different but undistinguishable.

    What we do at the moment is selecting a sample of GTracks having DHits at least in four layers (at least 4 hits are necessary for SvtTrackFinder to find a track) but having not more than once two DHits on a layer, to reduce the incidence of ambiguous tracks.