simonsobs / sotodlib

Simons Observatory: Time-Ordered Data processing library.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

coords.get_wcs_kernel should insist on sensible resolutions

mhasself opened this issue · comments

By which I mean that res should divide 90 degrees ~evenly. This is part of making a good fejer1 pixelization, for SHTs.

Add the check in the if proj == 'car': block, along with the crpix tweak.

"Evenly" can only be true to machine precision, or so ... imitate the pixell check equivalent to, abs(res*N - np.pi / 2) < 1e-8.

I've come up with a possible solution for this, but I think some clarity on "evenly" would be helpful.

I've added the following under the code block you mentioned.

        div = 90./res - np.round(90./res)
        if len(str(div).split('.')[1]) > 3:
            raise ValueError("Please use a standard resolution")

Here, div is essentially the decimal remainder from dividing into 90 degs. I then check and see if there is a "reasonable" amount leftover. So if the user supplies car-8deg, for example, then they won't get an error. But if they try `car-7deg', it will throw a ValueError.

So, I guess my question is about what is "reasonable"- is an 8 degree resolution reasonably even?

In the context of division, "evenly" means "without any remainder". So 8 deg does not divide 90 degrees evenly. 9 deg does. 10 deg does. 3 arcminutes does.

That makes the evaluation easier. I would want zero decimal places, in other words.

But please don't use string processing to answer numerical questions. It will bite you somehow. For example, div could be 0.00000001. That's a very small difference from zero, even though there seem to be lots of digits there.

You want to check that div is "very close to zero". Due to rounding and machine precision, there can sometimes be a small irrelevant residual, so instead of checking div == 0 you should check abs(div) < 1e-8. That's what my example code was getting at.

Addressed in #557