Skip to content

Normalization of alms #23

Open
Open

Description

@zonca

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

Activity

  1. mreineck commented on Jun 11, 2019

    @mreineck
    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.

  2. mreineck commented on Jun 11, 2019

    @mreineck
    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

  3. zonca commented on Jun 11, 2019

    @zonca
    MemberAuthor

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

  4. mreineck commented on Jun 11, 2019

    @mreineck
    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.

  5. mreineck commented on Jun 11, 2019

    @mreineck
    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))...

  6. dagss commented on Jun 11, 2019

    @dagss
    Collaborator

    @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.

  7. zonca commented on Jun 11, 2019

    @zonca
    MemberAuthor

    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?

  8. mreineck commented on Jun 11, 2019

    @mreineck
    Collaborator

    Yes, triangular.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions