Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 HLT GENERIC SIGNAL LOSSES ANALYSIS summer internship 2004 Philippe Kobel EPFL, Lausanne, summer internship 2004.

Similar presentations


Presentation on theme: "1 HLT GENERIC SIGNAL LOSSES ANALYSIS summer internship 2004 Philippe Kobel EPFL, Lausanne, summer internship 2004."— Presentation transcript:

1 1 HLT GENERIC SIGNAL LOSSES ANALYSIS philippe.kobel@epfl.ch, summer internship 2004 Philippe Kobel EPFL, Lausanne, summer internship 2004

2 2 Algorithm Goal fail ‘HLT-generic’ « For the events that should be triggered in MC but fail ‘HLT-generic’ (l1conf or dz) identifyspecific reconstruction error identify a specific reconstruction error responsible for not triggering @ given Output Rate » How ? - Separate HLT in 2 cutting variables: l1confdz l1conf (log pt0+log pt1), dz (svz – pvz) - Apply successive tests for possible failure sources l1conf tests: PV-IP-PT - 3 datasets analyzed (TDR): bpipi, bsdsk & bkstargamma philippe.kobel@epfl.ch, summer internship 2004

3 3 L1conf- Failure Sources & Tests l1conf = log (pt0) + log (pt1) PT Computed with the 2 highest PT tracks IPPV in IP window associated with a PV => 3 tests computed in order of depth: PV: « is the Primary Vertex OK? » IP : « are the B tracks in IP window? » PT : « is the PT underestimated? » 1st failed = responsible 1st failed = responsible for HLT failure ! philippe.kobel@epfl.ch, summer internship 2004

4 4 Getting Rid of Resolution & Cumulation Goal: specific reconstructionfailures –Identify specific reconstruction failures –Separate failures due to: - resolution : nothing we can do! - cumulation: not a clear responsible of the failure! Get rid of the resolution: –Use normal distrib. by comparing with MC Get rid of cumulation: –Use rec values for the test and MC values for the rest (using REC-MC link) => Advantage: Independent tests !!! philippe.kobel@epfl.ch, summer internship 2004

5 5 The B Philosophy keeping track of B tracksHLT goal: Detect signal evts by keeping track of B tracks → Look for B tracks in the tests! - Analyze only evts triggered in MC with mc B tracks ≠ by luck ! - If the rec evt fails l1conf-HLT, 2 reasons: 1) The rec B tracks are not in IP window 2) Their PT is underevaluated IP test example: ask if at least 2 B tracks in IP window philippe.kobel@epfl.ch, summer internship 2004

6 6 Classifying the evts in 5 categories @ given Output Rate (5,10,15 kHz): 1)Signal events NOT triggered in MC Signal events YES triggered in MC: 2) YES triggered by HLT-generic NO triggered by HLT-generic: 3) Because not reconstructed 4) Due to bad-reconstruction (in order of responsability) 5) Due to cumulation+resolution (no clear responsible) philippe.kobel@epfl.ch, summer internship 2004 Lost signal fractions = 1 !

7 7 L1conf- Algorithm ArchitecturePreselection Is evt part of signal ?  has mcB ? Is evt triggered in MC with mcB ’s ?  mc l1conf > l1cut? Is it lost in HLT bec. not rec ? Does the rec evt fail l1conf- HLT  l1conf < l1cut? NO nnomcB += 1 NO nnomctrig += 1 YES nnopv…nnol1conf += 1 nsuccess += 1 NO YES NO philippe.kobel@epfl.ch, summer internship 2004

8 8 L1conf-Table philippe.kobel@epfl.ch, summer internship 2004

9 9 L1 conf- General Test Structure → Take rec_x & rest MC 1) Is x = PV..PT bad rec ?  rec_x - mc_x > x_cut ? 2) Is it responsible for failure ? i) Less than 2 B tracks in IP ? (with MC partner in IP) ii) x_l1conf < l1cut (OR) ? 2 outputs: # evts having x bad rec # evts failing because x bad rec philippe.kobel@epfl.ch, summer internship 2004

10 10 L1conf- Algorithm ArchitectureTests: PV test 1) PV bad rec ? | pvz - mcpvz | > pv_reclim ? 2) Bad PV -> failure ? → redo MC analysis with PV i) Less than 2 B ’s in IP (having mc partner in IP) ? ii) pv_l1conf < l1cut ? YES nbadpv + = 1 NO YES badpvevts.append (evt) philippe.kobel@epfl.ch, summer internship 2004

11 11 Distributions & Rec limits Computed with the entire datasets (without cuts) dpvz = pvz - mcpvz pv_cut = 0.3 mm philippe.kobel@epfl.ch, summer internship 2004

12 12 L1conf- Algorithm Architecture IP test i) Less than 2 B ’s in IP window (with mcPV)? (having MC partner in IP) ii) Don ’t pass l1cut even if pt perfect (mcPT) ?  ip_l1conf < l1cut ? NO YES If evt not in badpvevts: badipevts.append(evt) philippe.kobel@epfl.ch, summer internship 2004 Disclaimer: We did not use the IP resolution plot here (upps!) because: small IP error → significant l1conf error

13 13 L1conf- Algorithm Architecture PT test 1) Is PT bad rec ? → Compute l1conf with the 2 highest PT partners of mcipcans  (pt_l1conf - mcl1conf)/mcl1conf > pt_reclim ? 2) Bad PT → failure ? ii) pt_l1conf < l1cut ? Fails due to res or cum NO YES If evt not in badpvevts & evt not in badipevts: badptevts.append (evt) ncum += 1 philippe.kobel@epfl.ch, summer internship 2004 YES nbadpv + = 1

14 14 Distributions & Rec limits pt_dl1conf = (pt_l1conf- mcl1conf) / mcl1conf pt_cut = 0.003 Bpipi peak: 3% of evts with less than 2 B’s in MC IP window (cf l1confirmation function) philippe.kobel@epfl.ch, summer internship 2004

15 15 Varying the OR Change the l1cut (dzcut) for 5,10,15 kHz Relaxing OR, subset of analyzed evts changes: - more evts triggered in MC - less evts fail HLT how wrongTo know how wrong we are: analyzed - Study fraction of analyzed evts (triggered in MC) lost rather than total signal fraction philippe.kobel@epfl.ch, summer internship 2004

16 16 Cutting Values for the 3 OR philippe.kobel@epfl.ch, summer internship 2004 OR (kHz)51015 l1cut161514 dzcut1252

17 17 L1conf-Table philippe.kobel@epfl.ch, summer internship 2004

18 18 L1conf- Varying the OR philippe.kobel@epfl.ch, summer internship 2004

19 19 L1conf- Varying the OR philippe.kobel@epfl.ch, summer internship 2004

20 20 L1conf- Varying the OR philippe.kobel@epfl.ch, summer internship 2004 40-50% lost by cumulation! ~ No losses due to PT-failures ~ No losses due to PT-failures PV failure significant 10-30 %! IP failures  : We don’t know the reason: resolution / bad reconstruction

21 21 Dz- Sources of Failure & Tests dz = svz - pvz OR DIRPTIP PV The node is reconstructed with the ORigin and DIRection of the 4 highest PT tracks in the IP window associated with a given PV Tests: PV : is the PV ok ? IP : 2 B tracks in the IP window? PT : 2 B tracks in the 4 highest PT’s in IP ? OR & DIR : are the tracks position and slopes ok ? philippe.kobel@epfl.ch, summer internship 2004

22 22 Dz- General Test Structure 1) Is x = PV…DIR bad rec ?  rec_x - mc_x > x_reclim ? 2) Is it enough → failure ? i) Less than 2 B tracks in IP ? ii) Less than 2 B tracks within the 4 highest PT tracks in IP? iii) chi2 > maxchi2seed ? iv) x_dz > dzcut ? philippe.kobel@epfl.ch, summer internship 2004

23 23 Dz-Table philippe.kobel@epfl.ch, summer internship 2004

24 24 Conclusions Goal: identify reason of failure on HLT-generic –Identify: a specific rec error (fully resp) –Separate: resolution and cumulation Studying OR vs L1conf = log(pt0)+log(pt1) –~40 % cumulation & resolution –~20 % PV relevant!, ~2% PT irrelevant –~40 % IP but here no separation resolution/rec!! Studying OR vs dz: –Cumulation dominant ~40% –Democratic share: PV,IP,OR philippe.kobel@epfl.ch, summer internship 2004

25 25 Perspectives Code in python: –Revisit with DC04: better PV and reconstruction! –Still some minor problems: IP Leak! Study properly the effect of the IP resolution in the IP test! –Redo with u-variable: combine (l1conf,dz) –Have a graphical display (python) Event by event study… philippe.kobel@epfl.ch, summer internship 2004

26 26 Thank you!! philippe.kobel@epfl.ch, summer internship 2004

27 27 Dz- Algorithm Architecture Preselection Is evt part of signal ?  has mcB ? Is evt triggered in MC with mcB ’s ? i) At least 2 mcB tracks in IP? ii) Among the 4 highest mcPT tracks in IP? iii) Give a node with chi2 < maxchi2seed? iv) mcdz > dzcut ? Is it lost in HLT bec. not rec ? Does the rec evt fail dz- HLT  dz < dzcut? NO nnomcB += 1 NO YES nsuccess += 1 NO YES NO nnopv += 1 philippe.kobel@epfl.ch, summer internship 2004

28 28 Dz- Algorithm Architecture Tests: PV test 1) PV bad rec ? | pvz - mcpvz | > pv_reclim ? 2) Bad PV → failure ? → redo MC analysis with PV i) Less than 2 B ’s in IP (with mc partner in IP) ? ii) Less than 2B among 4 highest mcPT in IP ? iii) chi2 > maxchi2seed ? iv) pv_dz < dzcut ? YES nbadpv + = 1 NO YES badpvevts.append (evt) philippe.kobel@epfl.ch, summer internship 2004

29 29 Dz- Algorithm Architecture IP test i) Less than 2 RC tracks B ’s in IP window (with mcPV)? (having MC partner in IP) ii) Are the linked MC tracks not among the 4 highest MC tracks Pt? iii) chi2 > maxchi2seed ? iv) ip_dz > dzcut ? NO YES If evt not in badpvevts: badipevts.append(evt) philippe.kobel@epfl.ch, summer internship 2004

30 30 Dz- Algorithm Architecture PT(order) test Take rec tracks associated with MC tracks in MC IP window & order them in PT (don ’t ask if are in IP window not to include IP errors ) ii) Less than 2 B tracks among the 4 highest PT tracks in IP ? iii) chi2 > maxchi2seed? iv) pt_dz < dzcut ? YES If evt not in badpvevts & evt not in badipevts: badptevts.append (evt) NO philippe.kobel@epfl.ch, summer internship 2004

31 31 Dz- Algorithm Architecture OR & DIR test Take the 2 rec B tracks associated with the mcnodepars & compares the modulus of the diff. of the orgin vectors & direction vectors i) One of the rec tracks has its origin too far from its MC partner dor > or_reclim ? ii) One of the rec tracks has its direction too different from its MC partner ? ddir > dir_reclim ? YES nbador += 1 nbaddir += 1 NO philippe.kobel@epfl.ch, summer internship 2004

32 32 Dz- Algorithm Architecture OR & DIR test 2) Bad OR/DIR enough → failure ? iii) chi2 > maxchi2seed ? iv) od_dz > dzcut ? Fails due to res or cum YES If gooddir & evt not in…: badorevts.append (evt) If goodor & evt not in …: baddirevts.append (evt) else: badodevts.apend (evt) ncum += 1 NO philippe.kobel@epfl.ch, summer internship 2004

33 33 Distributions & Rec limits ddir = |mcnodepars.direction[i] – nodepars.direction[i] | /2 dir_reclim = 0.0006 philippe.kobel@epfl.ch, summer internship 2004

34 34 Distributions & Rec limits dor = |mcnodepars.origin[i] – nodepars.origin[i] | /2 or_reclim = 40 for bpipi 80 for bsdsk 60 for bkstargamma philippe.kobel@epfl.ch, summer internship 2004

35 35 Dz- Varying the OR IP vs OR: Democratic! Strong channel dependancy - IP dominant for bpipi - OR dominant for bsdsk - PT irrelevant! philippe.kobel@epfl.ch, summer internship 2004

36 36 Dz- Varying the OR PT error still insignificant DIR error insignificant IP & OR error dominant ! IP profile channel dependent philippe.kobel@epfl.ch, summer internship 2004


Download ppt "1 HLT GENERIC SIGNAL LOSSES ANALYSIS summer internship 2004 Philippe Kobel EPFL, Lausanne, summer internship 2004."

Similar presentations


Ads by Google