You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to read alms I created with healpy from disk and transform them in the format expected by libsharp.
However it seems there is a different normalization between the alm I create with healpy and with libsharp.
Investigating this issue I even find some strange behavior, could you please take a look at this notebook and check if you find any mistake/algorithmic errors?
If I understand correctly, you are requesting real-valued a_lm from libsharp:
libsharp_order = libsharp.packed_real_order(lmax, ms=local_m_indices)
I don't understand how the analysis call can return complex-valued a_lm in such a case. (Disclaimer: I don't know the current Python interface of libsharp at all.)
In any case: for real-valued a_lm all entries with m!=0 are scaled by a factor sqrt(2), so this is probably the discrepancy you are seeing.
I can't try this myself at the moment, but I think you are interpreting the storage scheme of the real package a_lm incorrectly.
They are storing only the values that can be different from zero, i.e. the imaginary value for (l=0, m) is left out, leading to a data set that has minimal size, but can be quite complicated to interpret.
@zonca what Martin says is correct, but this discussion seems a bit on the head for me.
The real-packed storage is very convenient for some things, but very different from what Healpix-the-software is using.
If you want the Healpix storage scheme then libsharp certainly supports that directly. Perhaps support is needed for that in the Python wrapper though I cannot remember.
I didn't know libsharp supported the HEALPix storage scheme, I see there is a triangular and a rectangular order available in Python. Is one of them the same as HEALPix?
Activity
mreineck commentedon Jun 11, 2019
If I understand correctly, you are requesting real-valued a_lm from libsharp:
libsharp_order = libsharp.packed_real_order(lmax, ms=local_m_indices)I don't understand how the
analysiscall can return complex-valueda_lmin such a case. (Disclaimer: I don't know the current Python interface oflibsharpat all.)In any case: for real-valued
a_lmall entries withm!=0are scaled by a factorsqrt(2), so this is probably the discrepancy you are seeing.mreineck commentedon Jun 11, 2019
Sorry, I misread the notebook... the libsharp
a_lmare not complex-valued after all.For a description of the normalization, see e.g.
https://commander.readthedocs.io/en/latest/library_guide/sphere.html
zonca commentedon Jun 11, 2019
thanks, now normalization is clear.
What about that signal at
m=1which only appears in libsharp and not in HEALPix?mreineck commentedon Jun 11, 2019
I can't try this myself at the moment, but I think you are interpreting the storage scheme of the real package a_lm incorrectly.
They are storing only the values that can be different from zero, i.e. the imaginary value for (l=0, m) is left out, leading to a data set that has minimal size, but can be quite complicated to interpret.
mreineck commentedon Jun 11, 2019
To be explicit, the storage order for a given m is
Re(alm(0,m)), Re(alm(1,m)), Im(alm(1,m)), Re(alm(2,m))...
dagss commentedon Jun 11, 2019
@zonca what Martin says is correct, but this discussion seems a bit on the head for me.
The real-packed storage is very convenient for some things, but very different from what Healpix-the-software is using.
If you want the Healpix storage scheme then libsharp certainly supports that directly. Perhaps support is needed for that in the Python wrapper though I cannot remember.
zonca commentedon Jun 11, 2019
I didn't know
libsharpsupported the HEALPix storage scheme, I see there is a triangular and a rectangular order available in Python. Is one of them the same as HEALPix?mreineck commentedon Jun 11, 2019
Yes, triangular.