cone_coverage_approx - > erroneous results

[Theodlz]

Hi! I've been trying to use this crate for cone-search like operations. Here is an issue I ran into: I define my Layer at depth = 4, then use the cone_coverage_approx() methods to find the healpix that overlap with a cone at ra=291.319724, dec=-82.309285, radius = 300.0/3600.0 (300 arcsec). However, the pixels returned are erroneous, and not at the right depth.

Here's a quick example:

use cdshealpix::nested::get;
    let n = get(4 as u8);
    let (ra, dec) = (291.3197242629231_f64, -82.30928537900044_f64);
    let radius: f64 = 300.0 / 3600.0;
    let ipixes = n.cone_coverage_approx(ra.to_radians(), dec.to_radians(), radius.to_radians());
    println!("{:?}", ipixes);
    for healpix in ipixes.iter() {
        println!("healpix: {}", healpix);
        let (ra, dec) = n.center(*healpix);
        println!("ra: {}, dec: {}", ra.to_degrees(), dec.to_degrees());
    }

    // compute the healpix of the ra/dec
    let ipix = n.hash(ra.to_radians(), dec.to_radians());
    println!("ra: {}, dec: {}, healpix: {}", ra, dec, ipix);

This yields the error Wrong hash value: too large., when I try to compute the ra/dec of the resulting healpix, which makes sense as the result of the cone search is [11274, 11298], which clearly isn't at depth 4! even if the result of the cone search says that the max depth is 4.

I also tried doing let n = get(3 as u8) (3 instead of 4) to see if I could get the overlapping pixels at depth 4 this way, and I get [2818,2826], when the results should be [2818, 2824]. So it is indeed at depth + 1, but the results don't look quite right.

I compared these results with healpy and astropy_healpix, and the cdshealpix ones appear incorrect, and to be at the requested depth + 1. Any idea what might be happening? I wonder if this error forward propagates into mocpy as well?

[Theodlz]

Ok so it looks like if I take these results that appear to be at depth+1, get their ra/dec, then recompute the healpix at the requested depth, they are correct.

So the main problem here is that one requests the healpix at order N, and gets them at order N+1. If I request them at N-1 to hopefully get the results I would expect for N, they are incorrect though.

[Theodlz]

I extracted the logic from the cone search approx method and run that, I do find the right pixels that way. I wonder if it's once the resulting pixels gets passed as a BMOC builder object that something funky or undocumented happens?

[fxpineau]

@Theodlz ,
I think the problem is that cdshealpix is not compliant with the "principle of least astonishment" for people used to other libraries.

A BMOC stores HEALPix cells at various depth/order. The method iter returns the raw values stored in the BMOC. A raw value encodes 3 values:

• the cell depth/order;
• the cell hash/ipix value;
• a flag telling if the cell is fully covered for sure or not by the cone.

I have to check whether the methods to extract the 3 values from a raw BMOC value are public or not (and update the doc accordingly).

The method to get the list of cell number at the BMOC maximum depth (the depth used in the cone_coverage method), is
flat_iter. See the example in the cone_coverage_approx doc.

Thus, if you replace iter by flat_iter in your code, you should get the expected result.
(To lower the number of false positives, you may use cone_coverage_approx_custom)