[astro-ph/0409513] HEALPix -- a Framework for High Resolution Discretization, and Fast Analysis of Data Distributed on the Sphere

Authors:  K. M. Gorski, E. Hivon, A. J. Banday, B. D. Wandelt, F. K. Hansen, M. Reinecke, M. Bartelman
Abstract:  HEALPix -- the Hierarchical Equal Area iso-Latitude Pixelization -- is a versatile data structure with an associated library of computational algorithms and visualization software that supports fast scientific applications executable directly on very large volumes of astronomical data and large area surveys in the form of discretized spherical maps. Originally developed to address the data processing and analysis needs of the present generation of cosmic microwave background (CMB) experiments (e.g. BOOMERanG, WMAP), HEALPix can be expanded to meet many of the profound challenges that will arise in confrontation with the observational output of future missions and experiments, including e.g. Planck, Herschel, SAFIR, and the Beyond Einstein CMB polarization probe. In this paper we consider the requirements and constraints to be met in order to implement a sufficient framework for the efficient discretization and fast analysis/synthesis of functions defined on the sphere, and summarise how they are satisfied by HEALPix.
[PDF]  [PS]  [BibTex]  [Bookmark]

Discussion related to specific recent arXiv papers
Post Reply
Antony Lewis
Posts: 1941
Joined: September 23 2004
Affiliation: University of Sussex
Contact:

[astro-ph/0409513] HEALPix -- a Framework for High Resolutio

Post by Antony Lewis » September 30 2004

This paper reviews the Healpix pixelisation scheme. Obviously Healpix is an immensely useful package and a large volume of high quality software is already written.

I have two comments:

1). There is one significant disadvantage of Healpix relative to igloo pixelization schemes; namely, that pixels numbers in Healpix are restricted to the form [tex]12 \times n^2[/tex] where n is a power of two. i.e. if you want to increase the resolution you have to do so by a factor of four. This is quite a large factor both in memory and computer time (especially for inverses etc scaling as [tex]n^6[/tex]). By constrast an igloo scheme can be devised in many ways to give a number of pixels close to any number you like. This may be quite relevant for Planck where n=1024 is not really engouh, but n=2048 is getting on for overkill.

2). The equidistant cylindrical projection oversamples near the poles, and is perhaps justly criticised for this reason. However the transform time (for a given resolution at the equator) is virtually the same as with Healpix because the oversampling is in the [tex]\phi[/tex] direction which is a fast FFT that takes a small fraction of the computing time. An advantage of oversampling near the poles is that this is precisely where the Healpix pixelisation error is worst: i.e. the cylindrical project is to some extent putting more pixels precisely where you need them to improve the Healpix transform but at no extract computational cost. Of course the downside is that the total number of pixels is much larger with a subsequent cost in terms of memory and further processing.

David Larson
Posts: 11
Joined: September 25 2004
Affiliation: Johns Hopkins University

Post by David Larson » September 30 2004

There is a little bit more flexibility in the number of pixels than may immediately be apparent. The number of main (base) tiles does not have to be 12. Examples are given in the paper where it can be 6, 8, 9, 12, 16, or 20. It looks like any product of two small numbers is available. Using a different number of base tiles would mean writing new code, though.

Also, N_side doesn't strictly have to be a power of two. If you're willing to give up hierarchical ordering, it can be any (positive) integer. The ring ordering scheme should still allow you to store the pixels in a fits file. If you don't want to give up hierarchical ordering, N_side can be a power of any integer. For example, instead of increasing by a factor of 4 with each change in resolution, you can increase by a factor of 3^2 = 9, or 5^2 = 25. It is also possible to increase by a different factor at each change in resolution. That would mean any product of integers would be a valid value of N_side. While this may be more complication than people want to deal with (or write the code for), it does give finer control over the number of pixels used in the sphere.

Antony Lewis
Posts: 1941
Joined: September 23 2004
Affiliation: University of Sussex
Contact:

Healpix

Post by Antony Lewis » September 30 2004

I agree entirely with this: so in principle a wide variety of pixel densities could be obtained with this kind of scheme. However the Healpix software does not allow this kind of flexibility at the moment - the factor 4 scaling is hard coded throughout the code.

Krzysztof M. Gorski
Posts: 2
Joined: September 30 2004
Affiliation: JPL/Caltech

Post by Krzysztof M. Gorski » September 30 2004

David Larson already partially replied to point 1) raised by Anthony Lewis. I can add, however, that there is one more degree of flexibility
in HEALPix. The resolution parameter n_side can be actually changed
nearly arbitrarily. For example, rather than going up a factor of 2 from 1024 to 2048, one can work with n_side=1234, or enything else,
if that is desired. This would allow a great degree of resolution manipulation.

Of course, this only applies to "theoretical" aspects of work. By this I mean that if one chooses their preferred n_side and proceeds to generate sky maps with synfast, and analize them with anafast, or other
utilities (except fotr those which REQUIRE hierarchical tree structure
of the maps) there is no obstacle posed by HEALPix, the software can be
used, or slightly modified to deal with such applications.

However, this degree of flexibility does not obtain when confronting a data set which has already been made. The arguments for stepping n_side by factor of 2 were explained in HEALPix documentation and papers. The motivation was to support specifically the hierarchically structured data sets (as for dealing with multi-resolution CMB data sets).

If anyone would like to convince the makers of the large angular
resolution full sky maps beased on experimental data that hierarchical
tree structure thereof is unnecesary, HEALPix still can provide the data model and software ready to deal with that.

On Anothony's second point: Again, we attempted to discuss those issues
before in what was written about HEALPix. It is indeed very well known
that the geographic, or ECP, grids, or point-sets (from quadrature point of view) allow better error behaviour than both HEALPIx and Igloo, at roughly the same CPU time consumption level, for the price of large
oversampling near the poles. Nothing new here. But, "You can't both have your cake and eat it!" HEALPix was built to meet simultaneously
the requirements of hierarchical structure (based on preferably low number of base resolution elements - with flexibility allowed as discussed
in the recent paper), equal area pixels, and iso-latitude distrubution
of pixel centers. And - what you see is what you get ...
If these requirements are not desirable, some relaxation within HEALPix
data stracture and software is possible.

Regarding the statement "The equidistant cylindrical projection oversamples near the poles, and is perhaps justly criticised for this reason." I'd like to add that our own critiques were merely repetitions
of those expressed on numerous occasion in literature by both the
climate and geophysics researchers, who would often state the obvious,
namely that the mathematical structure forces super-resolution near the
poles, but the data acquisition usually occurs with fixed resolution instruments, as indeed the CMB experiments work. Again, this was
a principal driver for equal area pixels of HEALPix.

Krzysztof M. Gorski
Posts: 2
Joined: September 30 2004
Affiliation: JPL/Caltech

Post by Krzysztof M. Gorski » September 30 2004

On Anthony's second msg:
The hard coding of "4" is easily lifted, if so desired. Most important,
THIS IS POSSIBLE with HEALPix.
We will be happy to consider this an example of "User Feedback"
and implement in the next release of HEALPix. Some broader expression
of desirability would be good though.

Post Reply