-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arbitrary pixelation schemes? #16
Comments
With certain limitations, yes. Madam outputs are Healpix FITS maps and it would require a nontrivial amount of work to change that. However, your calling code could easily embed your pixel numbers into any Healpix map with enough pixels and re-interpret them upon reading the maps. If you are using Madam only for destriping, you could also project the destriped timelines from your code. There are two important issues about embedding other pixelizations into the nested Healpix pixelizations Madam expects:
|
Ah okay I see, that sounds like a reasonable work around and thanks for the quick response. On your second point, does that mean it is not possible to simply stop Madam from subdividing the maps internally? If not I suppose the best option to minimise fragmentation would be to simply have |
Even at However, the issue with performance is not limited to submaps. If pixel numbers are completely random, the memory access patterns will lead to repeated cache misses and cause the code to run much slower than possible. Just something to consider before launching large production runs. |
Is it possible to setup MADAM to use pixelation schemes other than HEALPix? E.g., some arbitrary WCS pixelation scheme on a cartesian grid?
The text was updated successfully, but these errors were encountered: