P latform stability and track fit problems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

P latform stability and track-fit problems PowerPoint PPT Presentation


  • 44 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

P latform stability and track-fit problems

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

DFITER

Get space points from track pars. (q)

DFTRAC

Time-space conversion

i < 1

DFBCOR

DFDRV

Get residuals, c2, V = dc2/dq

c2 > c2(old)

LEQU64

Vdq = q; q = q + dq

Dc2 < cut

CONVERGED

Max iter?

FAILED


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

Track

  • 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

Tries

DFITER

End Tries

Hits

Tries

DFITER

DFLIP

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

DFLIP

Get hits to flip

Sort; pick worst

Store track pars.

Flip hit

DFITER (15 times)

c2 < input

Restore track pars.

Return


A possible wish list

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 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!

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


  • Login