140 likes | 239 Views
Ftksim with rawhits. Anton Kapliy University of Chicago October 2, 2007. Status. Read and understood ftksim code Changed ~10 files in ftksim/ and lib/ Corrected a few minor bugs Can reconstruct tracks from rawhits :. Same track reconstructed from SP and RAW, respectively:. d0,mm. z0,mm.
E N D
Ftksim with rawhits Anton Kapliy University of Chicago October 2, 2007
Status • Read and understood ftksim code • Changed ~10 files in ftksim/ and lib/ • Corrected a few minor bugs • Can reconstruct tracks from rawhits: Same track reconstructed from SP and RAW, respectively: d0,mm z0,mm phi cot(theta) signed Pt chi2 hitmask sector E 0.298031 146.067888 -1.872326 0.177779 -6.429815 7.508274 16383 98972 E 0.270156 146.098046 -1.871744 0.177243 -6.592097 10.512912 16383 88816 • Still needs some testing & tweaking • Tried on Whbb -> too slow (w/ large SS size) • Ran on training sample
SS map 1 0 82 328 1 1 82 328 1 2 82 328 0 0 128 768 0 1 128 768 0 2 128 768 0 3 128 768 0 4 128 768 0 5 128 768 0 6 128 768 0 7 128 768 IsPix # width of SS width of module Numbers given here correspond to SS width of ~5 mm (PIX) and ~10 mm (SCT) Affected files: ss_hit.c and read_routines.c
Mapping of coordinates • Linear fit: P = Q*X + C • P = track pars (d0,z0 ...); X = hits (1..14) • Q, C – calculated in corrgen (per sector). • RAW ordering: x1,z1;x2,z2;x3,z3;x4,x5..x11 • SP ordering: x1,z1;x2,z2;x3,z3;x4,z4..x7,z7 • Mapping done via new array idim[isZ][plane] idim[0][0]=0; idim[1][0]=1; idim[0][1]=2... idim[0][13]=14; idim[1][13]==(-1) – undefined • Guarantees that corrgen & ftksim use the same ordering. Affected files: pmap_rd.h and pmap_rd.c; corrgen.c; track_linfit.c
Roadwarrior • With new majority logic, can use 9/11 tracks • Put in new variable, MAX_MISSING_HITS • Defaults to 1 (= accept 11/11 and 10/11) • Extra sorting loop (may compiles away) • Is it useful? Or will 9/11 tracks swamp the statistics and increase runtime? Affected files: ftksim_code1.c
Hitwarrior – reminder • For each event, we construct: List of accepted tracks • When adding new track to the list, compare with existing tracks. • If matched, choose track with better chi2 • If not, keep both • Issues: • Compare coordinate-by-coordinate – how? • Say, 11/14 coordinates match. Is it a match?
Hitwarrior - tolerances SP RAW • Before: hardcoded tolerances: • DeltaX in radians • DeltaZ in mm • Now: new map file: • DeltaX & DeltaZ in pixels/strips • Loaded via hwsdev_rd() • Stored in a global array hwsdev[0..13] • RAW values ~correspond to SP • Are these the best values? • Need more tweaking? 0 2e-3 1 1.82 2 2e-3 3 1.82 4 2e-3 5 1.82 6 2e-3 7 1.82 8 2e-3 9 1.82 10 2e-3 11 1.82 12 2e-3 13 1.82 0 8 1 44 2 14 3 44 4 20 5 44 6 38 7 38 8 48 9 48 10 57 11 57 12 67 13 67 Affected files: read_routines.c & ftksim.c (to load the map)
Hitwarrior – criteria for match • Consider two tracks: 1 and 2 • ncommon_hits = # common hits (out of 14) • Special case: (x1,y1) vs (x2,y2) – 2D hit • If x1=x2; y1!=y2, we don't count x's as a common hit! • When do we consider two tracks the same? • ncommon_hits >= 14 – NPLANES • SP: ncommon_hits >= 14-7 = 7 • RAW: ncommon_hits >= 14-11 = 3 • This should probably be tweaked. Any ideas for additional criteria for “sameness”? Affected files: ftksim_code1.c
missing_point_guess • New majority logic (by Guido?): • Guesses missing coordinates in 10/11, 9/11 etc • Linear algebra, so I didn't follow it line-by-line • Uses ROOT matrix classes • Before: if it failed, ftksim would quit • Occasionally does fail (w/ singular matrix error) • Rewrote the code to drop the track, not quit • Haven't tested much, but seems to work. Affected files: track_linfit.c, majority_fun.cxx
If 11/11 track has bad chi2 • Perhaps one of the hits doesn't actually belong to this track, and true hit is missing --> causes bad chi2 • Loop over all possible 10/11 tracks • Invoke missing_point_guess to get missing hit • Compare chi2 of each 10/11 track to 11/11 • Keep the best track • Issue: chi2 will naturally reduce for 10/11 • Propose to instead compare: • (newtrk->chi2 + nmissing) with oldtrk->chi2 • Where nmissing = 1 or 2 (whether 1D or 2D hit is missing) • Probably very little effect, so not important Affected files: track_linfit.c
Statistics • For each event, loop over matched roads • For each road, loop over all hit combinations • With 5mm/10mm SS, this is HUGE (>10k) • An event sometimes takes several minutes! • Do we need a cut on Ncomb? I.e. If there are too many tracks, could skip this road? • Or reduce SS size? • Or do some clustering on original hits • e.g., two adjacent pix -> 1 cluster hit
Preliminary: RAW(red) vs ipat Using training sample My suspicion • A lot of fakes: SS size? Hitwarrior tolerances? Hitwarrior logic? Bug? • Weird bias in curvature (more at negative): corrgen or ftksim?
Preliminary: RAW(red) vs SP Using training sample Note: This has slightly different hitwarrior logic • Look similar. Can do event-by-event comparison (but mult. tracks?) • Sorry – low statistics. Only 1000 events
Plans • Need to test the code and make sure all parts work (E.g, hitwarrior or 10/11 loops) • Hope to run on bsmumu and Whbb – after solving the statistics problem (ss size?) • Eventually should commit to CVS • Start thinking about forward disks – depends on Corrinne's implementation.