Skip to content

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 and bayestar_sky_map_toa_phoa_snr_pixel
  • Introducing the output-inclination option to bayestar-localize-lvalerts and bayestar-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 to localize 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 within tox.ini and the CI seem to differ - the maximum line length is 100 in the former, 79 in the latter --- should tox.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

Merge request reports

Loading