Photonics/Hit-Maker Time Bug
Jake Feintzeig
1
2
Contents
  This talk covers two separate but related bugs,
one 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
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
4
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
Discrepancy Varies with
Distance
5
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
IceCube
tdelay = ?
500 ns
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
IceCube
Photonics
tdelay = ?
500 ns
muon
488 ns
8
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
IceCube
tdelay = 38
500 ns
muon
Photonics
tdelay = 50
488 ns
9
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
10
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
Discrepancy Varies with
Distance
11
Hit-maker is off
by this amount
12
Hit-maker bug solution
  One possible solution: implement inverse timetransformation 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