clsim - implement dynamic DOM oversizing

[Jakob van Santen]

The DOM oversizing is a useful optimization for receivers far from the light source, but dangerous for nearby sources. Non-oversized simulation is, however, dog-slow. An adaptive DOM oversizing could accurately simulate light yields from tracks close to DOMs while still efficiently undersampling photons emitted far away from any DOM. A sketch:

• The kernels operate on I3CLSimSteps that represent a short segment of Cherenkov track (with the default oversizing, roughly 2 m long)
• Each I3CLSim step has a known position, and thus a known distance to the closest DOM
• The DOMOversizeFactor specific to that step can be set based on that distance (to first approximation, 1 below 20 m, where the 5x oversizing is known to distort the light yield, and 5 above)
• The number of photons in the step can be prescaled by DOMOversizeFactor*DOMOversizeFactor, and photon collisions calculated in the kernel with the specific DOMOversizeFactor

This means that segments of track close to DOMs (which are rare) are carefully simulated, but the vast majority of tracks that pass far from DOMs are simulated efficiently. This of course requires the I3CLSimLightSourceToStepConverters to know about the geometry, and also make a few extra geometrical calculations. As long as this is less than 25x slower, however, you still win.

[Jakob van Santen]

I am not allowed to spend time on this anymore, but would happily mentor a volunteer with more free time. There's a first crack at a partial implementation in projects/clsim/branches/dynamic-oversizing .

[David Schultz]

This would be really useful for the set-and-forget mentality of production. Never have to worry about low energy not getting the correct setting, because it happens automatically.

[Claudio Kopper]

keep in mind that if in doubt OversizeFactor?=1 is the correct setting (until we have the feature described in this ticket)

[Jakob van Santen]

This is probably more of a summer project, given the enormous number of volunteers clamoring to help.

[Jakob van Santen]

We reviewed the status of this at the Zeuthen simulation workshop and agreed that cweaver should continue toward implementing dynamic oversizing for each light source. One open item was the time budget for calculating the optimal oversizing. Here's an approach:

• At the nominal DOM size, approximately 2500 photons need to be propagated per meter of Cherenkov track
• Our fastest GPUs currently take approximately 10 ns/photon
• => 1 GeV of energy loss takes 125 microseconds to propagate (or 5 microsecond at oversize 5)

The worst case for this optimization is a situation where it's not actually needed, i.e. all the light sources end up being simulated at oversize 5. In that case, it's reasonable to require that the attempt at optimization not take longer than photon propagation itself, i.e. not longer than 5 microseconds per light source on average.

[Alex Olivas]

Moving to smartsheets.