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

Polarization convention and IAU compliance #107

Open
d3v-null opened this issue Sep 29, 2022 · 3 comments
Open

Polarization convention and IAU compliance #107

d3v-null opened this issue Sep 29, 2022 · 3 comments
Milestone

Comments

@d3v-null
Copy link
Collaborator

d3v-null commented Sep 29, 2022

  • Birli uses the same polarization convention as Cotter for backwards compatibility.
  • The Aips117 memo is ambiguous about which polarization convention to use.
  • This convention appears to currently be X as EW and Y as NS [Citation needed, it would be good to show some evidence here]
  • The IAU convention appears to be the opposite, X as NS and Y as EW [Note: it would be good to point to where speicifically it says this]

This is contentious topic and there are arguments for both staying consistent, and switching to the "correct" convention. Birli should be able to accommodate both options.

The plan is to:

  • introduce an optional command line flag that will flip from the polarisation convention
  • give people some time to play with this flag and provide feedback on the implications of switching convention
  • if the benefits outweigh the costs, then switch the default convention to IAU
@d3v-null
Copy link
Collaborator Author

d3v-null commented Oct 3, 2022

suggestion from @JLBLine :

we should add 'IAUORDER' keyword to the uvfits header which is either F for False or T for True. People could have a switch in their pipelines that just assumes this is False if the header isn't present for backwards compatibility.

@JLBLine
Copy link

JLBLine commented Oct 3, 2022

See this paper here with Figure 1 showing x = North and y = East as the IAU definition (the paper also cites the source of the definition). As for written evidence as to why most uvfits seem to have x = East, I can find an example in pyuvdata here that has x as being East (snippet of code that say the below - it's about beams, but should apply to uvfits as well I imagine):
# check the x_orientation
print(uvb.x_orientation)
east

@d3v-null
Copy link
Collaborator Author

d3v-null commented Jan 10, 2023

pyuvdata calls this "pol_order", and the options are either "CASA" or "AIPS". I kinda prefer this way of naming things

https://github.com/RadioAstronomySoftwareGroup/pyuvdata/blob/main/pyuvdata/uvdata/ms.py#L1885

edit: oops, that's the ordering of the pols, not the labelling of X and Y.

https://github.com/RadioAstronomySoftwareGroup/pyuvdata/blob/11e7129af5b105f066e505abb3383c41af3d6bcf/pyuvdata/uvdata/uvdata.py#L4562

CASA ordering has cross-pols in between (e.g. XX,XY,YX,YY)
AIPS ordering has auto-pols followed by cross-pols (e.g. XX,YY,XY,YX)

@d3v-null d3v-null added this to the v1.0 milestone Nov 12, 2024
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

2 participants