P latform stability and track-fit problems M. Moulson, T. Spadaro, P. Valente Tracking Meeting, 18 Jul 2001

Warning sign: platform dependence Test of DBV-10 on SunOS and AIX: Input: 1000 raw events Output in ksl stream: AIX: 11 events, incl. 3 not found on SunOS SunOS: 10 events, incl. 2 not found on AIX AIX or SunOS: 13 events Mostly KSTAG (one INTERTAG) 2 events found on both platforms with different length General caveat (?’s): Parameter space is huge; this is a quick survey Most tests done on very small (single-event) samples Tests should be done methodically once direction is clear

Where do the differences arise? Differences appear at track-fit level Reconstruction through PR identical including DTCE(1), DHRE(1) banks Differences appear in DBV-9 Test DBV’s 7, 8, 9, 10 on a single event (?) Reconstruction in general different in each version Same on AIX and SunOS platforms for DBV-7, 8 CVS history: changes in DBV-9 dconvr:Spatial resolutions from data vtxfin:Various small bug fixes Suspect effect from new parameterization of hit resolution

First-crack diagnostics Cannot eliminate effect just by switching off algorithms Kink finding, track joining, M.S., hit add./rej., etc. Hit flipping not switchable Fine t-s relations a possible exception Known changes correspond to onset of differences (?) Provide a plausible mechanism for effect Cannot eliminate effect by disabling code-optimization

Summary of first-crack diagnostics Input: 1000 raw events from run Table summarizes differences in ksl stream Opt.Fine t-sOther Algorith. In common Only SunOS Only AIXDiff evt. length Notes 811 y73 y812 yy9213 yyy8232 Standard config no res.y8331 Not binning of res. curves

DFITER: Fundamental track-fit routine DFITER DFBCOR DFTRAC DFDRV LEQU64 i < 1 c 2 > c 2 (old) Dc 2 < cut Max iter?FAILED CONVERGED Get space points from track pars. (q) Time-space conversion Get residuals, c 2, V = d c 2 /dq V d q = q; q = q + d q

Issues with DFITER and call limits DFITER called at various points at start of event after each hit flipped in DFLIP after DFMUSC, DFDEDX, etc. at end of event Max iterations in a single call: 8 On failure, convergence criterion relaxed and called again up to 15 times per track from most places up to 15 times more for dE/dx and at end of event Most tracks reconstructed differently show convergence problems

Beginnings of an explanation Track End Hits Tries DFITER End Tries Hits Tries DFITER End Tries Other Alg At first call to DFITER, parameters different by Inside DFITER, after LEQU64, difference increases to Differences accumulate with each call to DFITER Eventually jump bins in fine t-s Differences in % Problem exacerbated when convergence difficult Most critical track parameter: z Can diverge by tens of cm, esp. in DFLIP DFLIP

Notes on machine precision Why do we see differences at level at input to DFITER? In principle possible to have exact agreement between platforms for single calculation In practice depdends on optimization, autopromotion, rounding modes E.g., AIX: our standard compiler flags do not round in single precision but autopromote single to double Fair amount of code before this point; numerical errors accumulate rapidly Part of solution will involve: Tuning compilation parameters Promoting key parts of track fit to double precision NB: Matrix inversion already in double, looks OK Worst case: V -1 V = 1 to within < (diag), (off diag)

Problems with DFLIP DFLIP Get hits to flip Store track pars. DFITER (15 times) Sort; pick worst Flip hit c 2 < input Restore track pars. Return 1. Residuals and drift distances not updated if hit not flipped Basis for choice of next hit to flip Always assume previous hit was flipped 2. Failed DFITER calls count against max. retries Looser convergence if lots of hits to flip (lots of failures) Fewer calls to DFITER allowed If a hit won’t flip, do we want to retry? 3. Criterion for keeping flip: c 2 < input c 2 Flip is kept even if c 2 worse than best so far 4. More subjective issues No use of information on z- progression?

A possible wish list More study of the problem More sensible calling strategy for DFITER Small fixes to DFLIP (for now) Use l/2 instead of sampling for small drift distances Double precision at key points Compiler flags to consistently handle numerical inaccuracy Smoothing of t-s relations, resolution curves Evaluate efficacy of changes based on: parameter resolution, track c 2, L/R resolution accuracy, track splitting, machine stability While monitoring traditional quantities: efficiency, hit efficiency, purity, CPU time

A final note: Time is critical! August downtime will be only point in near future when large-scale reprocessing possible