Disambiguate between “polarization angle” and “orientation”

[ziotom78]

So far we have assumed that the “orientation” of a detector, as encoded by its ψ angle, was the same as the polarization angle. Unfortunately, this is not true in presence of an HWP, as the polarization angle is affected by the HWP but not the orientation.

This PR fixes the terminology over all the code and introduces the following naming changes in a few functions, which are however used internally and should not affect any existing code. However, it is better to mark the changes in this PR as breaking, as the functions are exported in the global litebird_sim namespace.

[ziotom78]

The breaking name changes are the following:

• compute_pointing_and_polangle → compute_pointing_and_orientation (private function);
• all_compute_pointing_and_polangle → all_compute_pointing_and_orientation (private function);
• polarization_angle → orientation_angle (private function); the argument poldir has been renamed to ordir too.

[paganol]

Hi @ziotom78, I like this change. Anyway I think we might want to add in this PR also the reworking of the effect of the HWP. Now if we pass an HWP object to get_pointings the returned angle is orientation+2ωt. We should remove this possibility and pass the HWP to scan_map together with the orientation.

[ziotom78]

Hi @ziotom78, I like this change. Anyway I think we might want to add in this PR also the reworking of the effect of the HWP. Now if we pass an HWP object to get_pointings the returned angle is orientation+2ωt. We should remove this possibility and pass the HWP to scan_map together with the orientation.

I was planning to do this in a separate PR because I would like to include this PR in the incoming 0.11 release. Do you think it's better to include the reworking of the HWP object in version 0.11?

[paganol]

I was planning to do this in a separate PR because I would like to include this PR in the incoming 0.11 release. Do you think it's better to include the reworking of the HWP object in version 0.11?

I was thinking to include the reworking of the HWP in this version and then the "on the fly" pointing computation in a future PR. But I don't have a strong opinion.. for sure we need to make clear that if you include the HWP in get_pointings the meaning of psi changes.

[ziotom78]

After a discussion with @paganol I'm going to merge this. It's just a small step towards a more extensive improvement in the way pointings and the HWP angle are handled by the framework.