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

Precessing beams #104

Open
akleroy opened this issue Jan 7, 2022 · 3 comments
Open

Precessing beams #104

akleroy opened this issue Jan 7, 2022 · 3 comments

Comments

@akleroy
Copy link
Contributor

akleroy commented Jan 7, 2022

This is a really minor issue, but ... Eric suggested writing it down when it came up in conversation. As far as I know we never actually precess beams when we precess the epoch of astrometry. In principle for really correct treatment this should be done, right? Or am I being a space cadet.

@low-sky
Copy link
Contributor

low-sky commented Jan 7, 2022

I think that BMAJ, BMIN, BPA will indeed refer to the coordinates of the original image. Precession will change that, but I would guess that the more common problem this would need to solve is in changing coordinate systems (e.g., RA/Dec -> l,b). Numerically, I think this would be carrying along the WCS information for a beam and then updating BPA given precessions or coordinate changes.

@keflavich
Copy link
Contributor

You guys are talking about putting beams into images projected in, e.g., J2022.01 coordinates? Or something else?

@akleroy
Copy link
Contributor Author

akleroy commented Jan 7, 2022

Just raising the general issue that standard bookkeeping is to record BPA as the orientation of the major axis. When precessing from, e.g., B1950 to J2000, north changes and this is not addressed in any software that I am aware. It's a small effect for this precession, but Erik raises the point that these keywords will also float through more major coordinate changes, with the big one being equatorial -> galactic. So some notation indicating the coordinate system for the original beam so that BPA can be interpreted OR (what I was raising) software processing of the beam params seem like a thing that should exist in principle. We've survived without this for decades (I think, AIPS might do it...) but seemed worth noting (Koch suggested filing an unlikely-to-be-resolved issue).

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