P latform stability and track fit problems
1 / 12

P latform stability and track-fit problems - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' P latform stability and track-fit problems' - oria

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
P latform stability and track fit problems

Platform stability and track-fit problems

M. Moulson, T. Spadaro, P. Valente

Tracking Meeting, 18 Jul 2001

Warning sign platform dependence
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
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
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
Summary of first-crack diagnostics

Input: 1000 raw events from run 18805

Table summarizes differences in ksl stream

Dfiter fundamental track fit routine
DFITER: Fundamental track-fit routine


Get space points from track pars. (q)


Time-space conversion

i < 1



Get residuals, c2, V = dc2/dq

c2 > c2(old)


Vdq = q; q = q + dq

Dc2 < cut


Max iter?


Issues with dfiter and call limits
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
Beginnings of an explanation


  • At first call to DFITER, parameters different by 10-5-10-6

  • Inside DFITER, after LEQU64, difference increases to 10-5-10-4

  • 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



End Tries





End Tries

End Hits

Other Alg

Notes on machine precision
Notes on machine precision

  • Why do we see differences at 10-5 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-1V = 1 to within < 10-12 (diag), 10-9 (off diag)

Problems with dflip

  • 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: c2 < input c2

    • Flip is kept even if c2 worse than best so far

  • 4. More subjective issues

    • No use of information on z-progression?

Problems with DFLIP


Get hits to flip

Sort; pick worst

Store track pars.

Flip hit

DFITER (15 times)

c2 < input

Restore track pars.


A possible wish list
A possible wish list flipped

  • 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 c2, L/R resolution accuracy, track splitting, machine stability

  • While monitoring traditional quantities:

    • efficiency, hit efficiency, purity, CPU time

A final note time is critical
A final note: Time is critical! flipped

August downtime will be only point in near future when large-scale reprocessing possible