stages.flux.daemon_flux module: remove numba jit decorators, clean up and add documentation, speed up interpolation/evaluation#930
stages.flux.daemon_flux module: remove numba jit decorators, clean up and add documentation, speed up interpolation/evaluation#930thehrh wants to merge 11 commits into
stages.flux.daemon_flux module: remove numba jit decorators, clean up and add documentation, speed up interpolation/evaluation#930Conversation
|
Failing workflows are due to #927 |
…owed any longer), no need to set calc_mode in setup_function, cosmetics
…> 5 statements), no need to set representation in compute_function, turn default energy grid into global variable with units [no ci]
|
Timings as of now: Let's see the how much 1) the external flux calculation by daemonflux, 2) the splining, and 3) the spline evaluation contribute ( One can tell that evaluating the splines in event-by-event mode takes roughly 75% of the total time. If we compare the pipeline IceCube_3y_neutrinos_daemon.cfg to IceCube_3y_neutrinos.cfg, the latter has the services flux.honda_ip + flux.barr_simple instead of flux.daemon_flux and performs its flux computations on a 200 x 200 grid. Between these two analysis configurations, the template generation time of the one using daemonflux is ~0.5 s slower on a single CPU. If the daemonflux pipeline employs the same 200 x 200 grid instead, the above PISA spline evaluation time drops from 0.6 s-> 0.4 s (template generation time still ~0.3 s slower than for IceCube_3y_neutrinos.cfg). |
|
@marialiubarska @jpyanez |
|
Hey, I'm not sure I understood if your question is on the reason we do 2d interpolation or on the choice of sepcific interpolation method. The reason for 2d interpolation is speed, because of how In terms of the specific method, I don't remember why |
|
The choice of |
|
Hmm, I'm not 100% sure, but I think it's not just daemonflux, 2d interpolation does take at least comparable amount of time to the grid evaluation. It's just that it was much faster then looping over events. There was a third method: for N events, sort them by energy and coszen into NxN grid, then use it to get flux from |
|
I remember we had a discussion with @afedynitch regarding this, maybe he also has some thoughts |
Based on my timings above, obtaining the fluxes from the external daemonflux dependency and creating the The other aspect is that the total template generation time on a single core is of the order of twice the Any timings from a fit including the |
…ctBivariateSpline for interpolation
|
I've now included an external numba-accelerated interpolation package as an (experimental) option. Compared to the above timings, the spline evaluation time is reduced by a factor of approx. 4, meaning it is now smaller than the total The event distributions given this initial speedup attempt differ at the sub-percent level; here are typical maximal and minimal absolute fractional differences between binwise count expectations: I've also generated 50 random combinations of the parameters of the Others seem to look very similar. Given the current speedup of ~50% for |
stages.flux.daemon_flux module: remove numba jit decorators, clean up and add documentationstages.flux.daemon_flux module: remove numba jit decorators, clean up and add documentation, speed up interpolation/evaluation
|
Since I'm not aware of a specific motivation behind the choice of the There does not seem to be any significant speed up once grid size drops below 100 values (compute time ~0.21 s), where the relative deviations are still very similar to those of template produced with the default grid though. At 10 (!) grid points, all relative deviations are at the percent level. energy grid with 200 log-spaced values
energy grid with 100 log-spaced values
energy grid with 50 log-spaced values
energy grid with 25 log-spaced values
energy grid with 10 (!) log-spaced values
|
…organise TODOs at top of module
…x in module [no ci]

On top of resolving #929, this PR fixes missing documentation and cleans up the module and demonstrates performance and accuracy in the notebook.