CDF tracking

I have looked at what tracks are found by ProductionExe when run with the standard tcl files on the tight Z sample (farms used release 4.3.1) and Z->ee MC in 4.4.0int4. The default process, I think, is to do

1. COT tracking
2. Outside-In tracking (which algorithm?)
3. Karlsruhe standalone tracking

• Tracks found in tight Z sample.
• Tracks found in Z->ee MC.
• It seems that there is a problem with the standalone tracking in 4.4.0int4, since there are no tracks found. There were also no standalone tracks found in the data sample when I dropped all the tracks and reran just standalone tracking with 4.0.0int4.
  • Looks like this is because you have to be running PVFinder in order for KalStandaloneTracking to work (see tcl below).
  • When I try to run PVFinder, it crashes on events where there is no SiHitSet, i.e. events where the silicon was turned off. I have reported this to cdf_software_help and Kurt Rinnert.
    • 03/16 Kurt says the crash is fixed. Also he made it possible to use vertices from a FastZVertexColl in the event rather than from PVFinder. But it now just takes the first one it finds...
  • I can fix the bug locally and try again...
• Now I get tracks! What I do is drop all tracks, and rerun SiPatternRecModule so that only KalStandaloneTracking is run:

                mod talk DHInput
                  dropList add CdfTrackIdManager CdfTrackColl CdfEmObjectColl
                  dropList add CdfTrackHits CdfTrackView
                exit
                # Need to enable PVFinder to do standalone tracking???
                mod enable PVFinder
                mod talk PVFinder
                  SAS3DPVFinder set t
                  TrueVertices set f
                exit
                mod disable CT_TrackingModule
                mod enable SiPatternRecModule
                mod talk SiPatternRecModule
                  PerformOutsideInTracking set f
                  PerformOIZTracking set f
                  PerformKalSvxStandaloneTracking set t
                exit
                mod enable CdfEmObjectModule

• Here are the tracks found in tight Z sample, kal standalone only.
  • Note that we expect no COT or OI tracks because we have not run COT tracking!
  • The efficiency for the standalone tracks is quite low, even in the region 1 < |eta| < 2, where all 7 layers of (non-L00) silicon should be available.
  • Number of silicon layers used for those standalone tracks (blue tracks in the plot above).
  • Here is a hapless E over p plot for those standalone tracks.
  • Here are deltaX and deltaZ for central electrons with tracks. They are pretty awful too, but at least you get the idea that the track may actually be physically related to the electron...
• I think setting the X0 and Y0 to something other than 0,0 may help. Where can I find the typical beam offset? (I am assuming that since these are talk-tos, that means they are not picked up automatically from the database...)
  • There was a problem (maybe only on linux?) where I couldn't set BeamX0 or BeamY0 to a negative value. Fixed by adding the last two arguments in the following lines in SiPatternRecModule.cc:

                     _x0("BeamX0",this,0.0,-1,1),
                     _y0("BeamY0",this,0.0,-1,1),

    And now I can run with BeamX0=-.17, BeamY0=.42.
  • I noticed that the L3 tcl file uses

                     BeamX0 set -0.1181
                     BeamY0 set 0.4130

    It is talking to a different module but presumably for the same purpose. Why the difference in the X offset?
  • Here are some plots:
    • Tracks found
    • E over p
    • Number of Si layers
  • Efficiency improves by about 50%!! E over p doesn't look too much better, though...
• Apr 1, 2002 OK, now try the same as above but use some alignment from the database.
  • Using the snippet

    AlignmentSource set "ofotl_prd_read    100021    3    TEST"

    we get:
    • These tracks found.
      • No clear improvement, but it certainly changes which tracks were found.
    • E over P.
      • This may be a slight improvement, but it's hard to tell.
• That's all for now. It seems that alignment will be important. Concentrate now on aligning the ISL and on getting the algorithm to work well with MC. (Includes PVFinder efficiency improvements.)