Draft: Add inclination angle samples to the output skymap
This MR accomplishes the following tasks:
-
Saving the inclination angle samples as part of the low-level functions bayestar_sky_map_toa_phoa_snr
andbayestar_sky_map_toa_phoa_snr_pixel
-
Introducing the output-inclination
option tobayestar-localize-lvalerts
andbayestar-localize-coincs
-
At the moment, this is implemented in a very simplistic way: the inclination angle samples are computed for either value of the option, they are just not included in the final skymap if the option is turned off. It may be worth it to propagate the flag down to the C code for efficiency.
-
-
Adapting the rasterize
function so that it also correctly applies to the*_SAMPLES
columns of the skymap-
This often results in very heavy output files. Should we change the rasterize
default to only'PROBDENSITY'
or['PROBDENSITY', 'DISTMU', 'DISTSIGMA', DISTNORM']
being rasterized?
-
-
Adding some unit tests for the skymap as part of test_bayestar.py
- Checking for the correct normalizations of both the samples and the probability density
- Checking for the correct columns being present when the
output_inclination
option tolocalize
is either on or off - Refactoring the tests using module-scoped fixtures so that the single-detector skymap is only computed once
The new columns being added to the skymap are named ['PROBDENSITY_SAMPLES', 'DISTMU_SAMPLES', 'DISTSIGMA_SAMPLES', DISTNORM_SAMPLES']
.
Each of them contains 10 entries, corresponding to 10 equally-spaced inclination angles between 0
and \pi
.
The quadrature scheme for the inclination integral is also switched here to Clenshaw-Curtis quadrature (whereas it was Gauss-Legendre quadrature before).
The work within this MR is heavily based on a previous implementation by @leo-singer.
Other minor points:
-
should we include some utility functions within the postprocess
module for common tasks such as computing skymaps conditioned on a given inclination angle? -
the settings for flake8
withintox.ini
and the CI seem to differ - the maximum line length is 100 in the former, 79 in the latter --- shouldtox.ini
be updated? -
should I document this change as part of release 1.1.3 or 1.2.0? To me it seems like a significant enough difference in interface to warrant a new minor release number.
Edited by Jacopo Tissino