Re-introduce the "regression" parameter to map analysis?

[mreineck]

I just noticed that at some point the "regression" parameter, which allowed separate treatment of the map monopole in the spherical harmonic analysis, seems to have vanished.
In my opinion this should be reverted, since I convinced myself that separation of the monopole and the remainder of a map will always provide a more accurate a_lm result. I can understand that, for compatibility with with traditional Healpix, this feature should be optional (although I'd recommend against switching it off by default); completely removing it seems a disservice to the user.

[lpsinger]

Looks like this was removed in #173.

[mreineck]

Thanks! I must have missed the discussion...
Actually, from reading this it seems to me that the original approach simply removed the monopole, but did neither re-add it to the map at the end of the function call nor fixed the a_00 coefficient accordingly. My idea was simply to pass a average-subtracted map to the C++ code and add "average_sqrt(4_pi)" to the a_00 component it returns.
From the user's perspective nothing fundamental would change, except for the result being slightly more accurate.
Maybe the name "regression" isn't right for this functionality, but it would certainly be very nice to have in some way or other.

[mreineck]

To clarify, I'd imagine the map2alm function to do something like this (sorry, pseudocode only):

function map2alm (map, alm, special_monopole)
  if (special_monopole)
    avg=map.average()
    map2 = map-avg
    alm=healpix_c++.map2alm(map2, alm)
    alm(0,0)+=avg*sqrt(4*pi)
  else
    alm=healpix_c++.map2alm(map, alm)

[zonca]

it looks like a good idea, let's see if somebody can contribute this improvement, otherwise I'll work on in in the next few weeks

[mreineck]

Hmm, even though I started this discussion, I'd suggest that we let this lie for a few weeks ... I'm currently working on improving map analysis in other ways that might make this obsolete.

[zonca]

@mreineck I'm reviewing old issues, do you think removing monopole before passing to C++ is still a good idea?

[mreineck]

There are two aspects to this:
It all depends on what the user wants to do: if the goal is "give me the best possible approximation of the a_lm corresponding to this map", then the monopole should be subtracted and the bests possible weights should be used.
On the other hand, if the goal is "do the adjoint of the alm2map operation I just carried out`, then the monopole should not be subtracted and no weights should be used. And this latter scenario is quite common in map making.
I fear there is no simple answer to this.

[zonca]

I would call this option disable_separate_monopole=False and set it False by default.
Then explain in the docs what you wrote here.

We are changing the default behavior but I think we do it for the better because by default we will give better results.

So people doing mapmaking or similar advanced operations can set it to True.
I would also propagate this argument to anafast,
I don't think it is necessary to propagate it to smoothing.

@lpsinger any thoughts?

[mreineck]

This all boils down to the fundamental misconception that there is such a thing as an inverse alm2map transform ... only because the interface (which dates back to the original Fortran interface) strongly suggests that this is the case. It took me years to fully realize this misunderstanding.

I know it's radical, but I'd suggest removing alm2map and map2alm altogether and replace them by:

• synthesis (formerly known as alm2map)
• adjoint_synthesis (the adjoint of synthesis, no complicated flags necessary)
• approximate_analysis (weighted and/or iterative application of adjoint_synthesis, including monopole/dipole removal and other special effects, with special caution required concerning lmax etc. etc)

This would make it painfully obvious to everyone that map analysis is not something that works out of the box. In contrast, the first two operations are conceptually very simple, and this will be reflected by the fact that they don't require any extra fancy parameters.