Producing sky models as spherical harmonic coefficients?

[mreineck]

Many current simulation efforts are working with non-axisymmetric beams and partially with rotating half-wave plates, and to implement these effects efficiently, an input sky given in the form of a_lm is much preferrable to, say, Healpix sky maps.
Of course this can be obtained by running a map analysis on the outputs of the sky model, but I wonder if it wouldn't be advantageous to actually run as many of the sky model calculations as possible in harmonic space as well. Advantages would include

• no accuracy loss during rotations
• no accuracy loss (and much higher performance) when smoothing
• input "maps" to the sky model components could be stored as a_lm as well. If that is done, only one set of a_lm is sufficient for all possible output resolutions, since a_lm can be read in to any desired band limit, as opposed to maps, where either maps at different resolutions have to be stored, or downscaling must be performed.

There are of course some components where at least some of the calculations have to be performed in position space, but these would simply be treated as before, and the maps internally converted to a_lm at a convenient stage.

I have suggested this to the pysm developers as well, but have not had a response yet (galsci/pysm#90 (comment)). @hke, do you think such an approach could be generally useful?

[hke]

In Commander2/3, we are in fact modelling the amplitude of diffuse components in terms of a_lm's rather than as pixelized maps. The maps are just converted to Healpix maps on output for visualization purposes. And a main motivation for this is precisely to be able to do multi-resolution beam smoothing for different channels easily during the Conjugate Gradient solution.  That being said, spectral indices are more naturally defined in terms of pixelized (or regionalized) maps. In our experience, it's better to choose the basis based on the physical properties of the quantity in question, and what is the actual free parameter we want to optimize, rather than what is computationally convenient; if we have to pay an extra SHT or two, that's better than introducing nasty parameter correlations during the MCMC sampler, which may happen if one chooses a sub-optimal basis. ti., 26.03.2024 kl. 06.09 -0700, skrev mreineck:

…

Many current simulation efforts are working with non-axisymmetric beams and partially with rotating half-wave plates, and to implement these effects efficiently, an input sky given in he form of a_lm is much preferrable to, say, Healpix sky maps. Of course this can be obtained by running a map analysis on the outputs of the sky model, but I wonder if it wouldn't be advantageous to actually run as many of the sky model calculations as possible in harmonic space as well. Advantages would include  * no accuracy loss during rotations  * no accuracy loss (and much higher performance) when smoothing  * input "maps" to the sky model components could be stored as a_lm as well. If that is done, only one set of a_lm is sufficient for all possible output resolutions, since a_lm can be read in to any desired band limit, as opposed to maps, where either maps at different resolutions have to be stored, or downscaling must be performed. There are of course some components where at least some of the calculations have to be performed in position space, but these would simply be treated as before, and the maps internally converted to a_lm at a convenient stage. I have suggested this to the pysm developers as well, but have not had a response yet (galsci/pysm#90 (comment)). @hke, do you think such an approach could be generally useful? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mreineck]

Thanks, this is going exactly in the direction I was thinking of!

For the components that have spatially varying spectral indices it would of course be a huge hassle to work in hte harmonic domain, and I didn't mean to suggest that! I'd just do it for the components that are equally easy to treat in pure a_lm form, and I think there are quite a few.

But even for the other components it might be worth considering to switch from Healpix to, say, Gauss-Legendre or equidistant grids for the real-space operations, since the spherical harmonic analysis is should be more accurate there. Of course, once you perform nonlinear operations, the band limit of he map goes out of the window anyway, but switching to a grid where a simple a_lm -> map -> a_lm computation gives you the input back with 12 significant digits (compared to roughly 3-5 digits for Healpix) could be advantageous.

[hke]

I'd be OK with switching to a non-Healpix grid for purely internal operations, such as beam convolution, B*a, but I doubt it's a good idea in general for quantities that actually will be provided to the user, such as the final map, the noise rms, the spectral indices and so on. For those, the practical advantage of having a community-wide standard is much higher than obtaining higher SHT accuracy, I think. But for purely internal calculations, this is definitely a good idea, and something we should build into the next-generation Commander4 map class :-) fr., 29.03.2024 kl. 00.04 -0700, skrev mreineck:

…

Thanks, this is going exactly in the direction I was thinking of! For the components that have spatially varying spectral indices it would of course be a huge hassle to work in hte harmonic domain, and I didn't mean to suggest that! I'd just do it for the components that are equally easy to treat in pure a_lm form, and I think there are quite a few. But even for the other components it might be worth considering to switch from Healpix to, say, Gauss-Legendre or equidistant grids for the real-space operations, since the spherical harmonic analysis is should be more accurate there. Of course, once you perform nonlinear operations, the band limit of he map goes out of the window anyway, but switching to a grid where a simple a_lm -> map -> a_lm computation gives you the input back with 12 significant digits (compared to roughly 3-5 digits for Healpix) could be advantageous. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>-

[mreineck]

I completely agree :)