Skip to content
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

Normalization of alms #23

Open
zonca opened this issue Jun 10, 2019 · 8 comments
Open

Normalization of alms #23

zonca opened this issue Jun 10, 2019 · 8 comments

Comments

@zonca
Copy link
Member

zonca commented Jun 10, 2019

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?

https://nbviewer.jupyter.org/gist/zonca/a481471543cd6f658dea5bd48d0f94e9

@mreineck
Copy link
Collaborator

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.

@mreineck
Copy link
Collaborator

Sorry, I misread the notebook... the libsharp a_lm are 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
Copy link
Member Author

zonca commented Jun 11, 2019

thanks, now normalization is clear.
What about that signal at m=1 which only appears in libsharp and not in HEALPix?

@mreineck
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

dagss commented 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
Copy link
Member Author

zonca commented Jun 11, 2019

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?

@mreineck
Copy link
Collaborator

Yes, triangular.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants