=============================================
Minutes of Tracking Meeting, October 18, 2007
=============================================

taken by U. Husemann


Sebastian Grinstein: First Look at Gen7 B-Tagging
=================================================

- Sample: ttbar + minbias, 4 samples between 50e30 and 300e30
- 6.1.2 vs. 6.1.4int10
- Expect drop at high |eta|: fewer IO tracks, more (unused) Backward tracks
- Vertex: more vertices, more tracks, about the same error
- High-pt leptons and jets similar
- Good tracks: expect tagging efficiency proportional to number of good tracks
- Reduction of number of tracks after z0 cut and number of SVX r-phi hits 
  cuts: caused by tightened cluster cuts on SVX?
- Asymmetry in z0 distribution reduced in Gen7 (Gen6 shows shoulder)
- Tagging efficiency (tight SECVTX):
  o 4-5% higher in central region (OI only) in Gen7 
    (but slightly less efficient for large eta because of loss of
     IO tracks, will be regained by Backward tracks)
  o Mistag rate unchanged
- Checking details for reason of increase: same number of pass1 tracks 
  (better "good" tracks? better vertex chi^2?)
- Current B-tagger ignores Backward tracks, expect higher mistag rates
  when Backward tracks are included


Slava Krutelyov: COT t0 calibration in Gen7
===========================================

- Without t0 calibration: Large (1ns) variation in track t0 vs. phi
- Goal: t0 resolution of <100 ps
- Wire-by-wire calibration: best results for a single run but problematic 
  if one run represents large period -> choose mean t0 per cell pair
- Result: method works fine both with a single run and across run
- Q: why is t0 shifted below 0? 
  A: Bias in approximation? Could correct for bias afterwards.
- Track time vs. phi meets spec: better than 100 ps
- COT alignment files available for Silicon alignment


Oliver Stelzer-Chilton: Gen6-Gen7 COT Tracking Checks
=====================================================

- Signals: J/psi->mumu and Z->mumu data
- Loose J/psi muon selection: only slight difference in yield
- Tighter J/psi selection (5 hits in all COT superlayers): 
  o 13.5% higher Gen7 efficiency
  o Reason: recovery of SL1 efficiency in Gen7
- Comparable resolutions in d0, J/psi mass, etc.
- Z->mumu: slightly more lose Zs, but slightly worse resolution
- Fakes from same-sign muons: 4-5 events, are they the same events?


Matt Herndon: J/psi Validation
==============================

- Using J/psi selection with private track refit (same for Gen6 and Gen7):
  does not get full picture of change between version
- COT J/psi mass: slight efficiency loss (1.4%)
- Silicon J/psi mass: same as before, fine at higher pT
- More COT hits, worse COT chi^2 (but not sure how shown chi^2 is defined)
- Fewer silicon hits: due to new tighter clusterin cuts?
- Silicon attachment efficiency: 0.5% drop (but 2.5% for z sensors)
- Silicon d0 (vs. phi) resolution unchanged
- Fakes (defined as tracks with negative impact parameters): 
  small effect overall, but 8% worse in Gen7


Antonio Boveia: High pT Dimuon 6/7 Comparisons
==============================================

- Reprocessed Period 8 with 6.1.4int10, 2.75 Mevents, 176/pb
- Muon categories: minimal - triggerable - tight (a la Joint Physics)
- Interesting: Z reconstructed from one Joint Physics tight muon and
  one forward muon (COT exit radius <140 cm)
  o Bad mass resolution, but reasonably looking pt spectrum: 
    geometric or algorithmic problem?
  o Would like to see comparison of old IO with new IO plus Backward tracks 
    (disentangle from SiSA, which we don't know how to operate)



Discussion: Making the case for Gen7 tracking
=============================================

- Reasons for switching to Gen7 tracking, all need work to make the case:
  o L00 performance in high hit density environment (e.g. b-tagging in data!)
  o Forward acceptance (e.g. for Higgs search)
  o Quantify the quality of central and forward tracks
- Timing and CDF computing model: discussion on how bad is increase in 
  computing time (say 50%) for Gen7?
  o 60% of CDF computing power is used for production, ntupling, and MC
  o 40% user code
  o Can we afford to take away computing power from users to satisfy 
    tracking needs?