search

radio-astro-tools / radio-beam

A simple toolkit for reading and manipulating beams from astrophysical radio spectral data cubes.
https://radio-beam.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
26 stars 21 forks source link

Precessing beams #104

Open akleroy opened 2 years ago

akleroy commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

akleroy commented 2 years ago

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