-
Notifications
You must be signed in to change notification settings - Fork 10
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
Brute force convolution test? #8
Comments
Hi Martin, I think this would a really valuable test! We have done similar tests before we implemented the non-ideal HWPs (see |
Thanks! I will work on this next week and ask you for help when (not if) I get stuck! |
Here is a rough first sketch demonstrating what I have in mind. To get exact spherical harmonic transforms I had toi make it depend on I'm certain that there are still a lot of mistakes in the details, but do you think this is going in the right direction?
|
I have added a Python script with the first beginnings of such a test at https://github.com/mreineck/beamconv/tree/low_level_tests. There are still a few problems, most likely because my application of the Mueller matrix is wrong... for example if I change the (2,2) element to Questions:
|
I have added some documentation to the test code. At the moment I'm a tmy wits' end concerning the problem with the Mueller matrix. Any insights would be more than welcome! |
One observation, which is a bit disconcerting (at least to me): An ideal HWP with no rotation basically flips the sign of the Stokes U component (let's ignore V for the moment) and leaves Stokes I and Q unchanged, correct? I just observed that if I take a band-limited Stokes IQU map and flip the sign of U, the resulting map is not band-limited any more. If that's correct, my approach (which involves synthesizing a sky map from the a_lm, applying the Mueller matrix pixel-wise, and then analyzing the resulting map) cannot work ... |
Hi Martin, Sorry for reacting so slowly, I should have more time after coming Thursday. About your last point: I agree that the Mueller matrix of an ideal HWP is given by diag(1, 1, -1, -1). And I think you're also right about the band-limit increasing when you change U to -U. I tested it with GL pixels and with Healpix pixels and it happens in both cases. The extra signal seems to be localized around the poles. I can't really wrap my head around why that is happening. Q -> Q, U -> -U could be interpreted as a parity transformation, but I don't see how that increases the band-limit. Or, you could interpret Q -> Q, U -> -U as a complex conjugation of P = Q + iU, but I still don't see how that increases the band-limit. Let's perhaps discuss this tomorrow when we meet. I don't think it's very easy to trick beamconv to use theta and phi directly. I'll let you know if I find a way to do it. Another thing for your test: perhaps it would be interesting to think about applying the rotated HWP matrix to the beam before rotating it to the position on the sky instead of applying it to the sky. I think that might make the comparison to beamconv easier to interpret, since in beamconv the HWP angle is defined with respect to a coordinate frame fixed to the telescope. When using that definition one should rotate the HWP angle with respect to the sky when rotating the beam. |
Concerning the loss of the band limit, this could be a somewhat intuitive example: Assume that the map is using a pixelization with a ring directly at the North Pole, i.e. where all pixels on the first ring actually fall in the same place. In that case, Q and U in these pixels must follow |
I have switched the test to the complex-valued variant including the |
I'm thinking about contributing a test which computes the measured detector signal for a single sample by brute force, according to the following recipe:
s_lm
andb_lm
(T,E,B,V components);M_{HWP}
(4x4 real numbers);theta, phi, psi, alpha
b_lm
to the proper orientation usinghealpy.rotator.rotate_alm()
(usesb_lm, theta, phi, psi
)s_lm
to maps (probably Gauss-Legendre to avoid inaccuracies)M_{HWP}, alpha
)b_lm
to maps (probably Gauss-Legendre to avoid inaccuracies)This is of course an extremely expensive way to compute a single sample, but it may be useful to verify the beamconv results for fully general Mueller matrices. The same sort of test (without HWP) is used in https://github.com/mreineck/ducc/blob/135ef6fb68b231cfbd862ab5351f0c9ef9afc44f/python/test/test_totalconvolve.py#L107-L134 and has served me well so far.
Do you think such a test would be a useful addition to
beamconv
?The text was updated successfully, but these errors were encountered: