Photonics/Hit-Maker Time Bug Jake Feintzeig 1 2 Contents This - - PowerPoint PPT Presentation

Photonics/Hit-Maker Time Bug

Jake Feintzeig

1

Contents

 This talk covers two separate but related bugs,

• ne in photonics and one in hit-maker

 Photonics time transformation bug

 Overview  Details  Time transformation plot  Example  Summary and solution

 Hit-maker bug

 Details  Summary and solution

2

Photonics Time Bug - Overview

 Photonics bug affects: anything that uses time pdfs/cdfs with level2 tables

 Simulation and reconstruction of muons  Hit-maker  Photorec  Not finiteReco, surprisingly  Not millipede (uses level 1)

 The bug is a systematic timing offset that varies with track-DOM distance, but is on the order of 10 ns

3

The Details

 In the level 2 tables reading routine, photonics does a time transformation to “internal residual time format” that depends on the difference between the internal table group velocity (what was simulated) and the external IceCube group velocity…yes, they’re different  In place to ensure there are no negative time residuals, since photons of different wavelengths propagate at different speeds  The result is a time shift is added or subtracted depending on whether you ask photonics for a Time or a Probability  Everything is very confusing  The bug is a math error in the time shift calculation

4

Discrepancy Varies with Distance

5

Example - Simulation

• > Hit-maker asks photonics: Given a source

and receiver configuration, how far after the IceCube geometric time will a photon arrive?

• Let’s say tgeo = 500 ns in IceCube

convention 500 ns

IceCube

tdelay = ? muon

6

Example - Simulation

• > Hit-maker asks photonics: Given a source

and receiver configuration, how far after the IceCube geometric time will a photon arrive?

• Let’s say tgeo = 500 ns in IceCube

convention

• Photonics table has delay times w/r/t the

geometric time of the fastest photon, which has a tgeo < 500 ns in Photonics 500 ns 488 ns

IceCube

tdelay = ?

Photonics

muon

7

Example - Simulation

• > Hit-maker asks photonics: Given a source

and receiver configuration, how far after the IceCube geometric time will a photon arrive?

• Let’s say tgeo = 500 ns in IceCube

convention

• Photonics table has delay times w/r/t the

geometric time of the fastest photon, which has a tgeo < 500 ns in Photonics

• To account for this, photonics transforms

the time from the table into IceCube’s convention 500 ns 488 ns

IceCube

tdelay = 38

Photonics

tdelay = 50 muon

8

Summary and Solution

 For much of our data (tracks ~ 100m from DOMs), the bug in the time shift is on the order of ~10 ns  The bug is easily fixed - plan is to cut a new release of photonics and update i3ports

9

Hit-maker bug

 Photonics subtracts time when it returns a time delay, and shifts a pdf forward when it returns a probability (essentially adding time)  In binning mode, hit-maker uses I3PhotonicsService::GetTimeDelays() for DOMs with hits below a certain PE threshold, and GetProbabilityDensity() for DOMs above threshold  Hit-maker can miss early charge

 Asks for probability starting at time=0 (IceCube), which gets transformed to time>0 in Photonics

10

Discrepancy Varies with Distance

Hit-maker is off by this amount

11

Hit-maker bug solution

 One possible solution: implement inverse time- transformation in hit-maker to get correct start time  Instead of asking for probability starting at t=0, hit-maker will ask for probability starting at the correct negative time  Nathan Whitehorn will do this when he rewrites hit-maker

12