Accounting for aberration in plane of sky coordinates

[Joshuaalbert]

I couldn't find where you accounting for aberration in the calculation of lmn coordinates. All the calculations seem to be ignorant of time. These coordinates are conjugate to the uvw coordinates, and thus also have an effect related to motion of the observer relative to the inertial reference frame of the coordinate system. For the UVW there are two inertial reference frames often used: Solar system barycentre, and Earth's barycentre. CASA use's Earth's barycentre in the UVW calculation, VLBI uses solar system's. In both cases, the orientation of the frame exactly matches ICRS coordinate frame, so that l/u points along RA and m/v points along DEC.

What this means is that if you convert RA/DEC into l and m without taking into account motion, i.e. time, you'll get wrong results.

To illustrate this here I plot the astrometry error over the plane of sky (l,m coords) induced by aberration (and what happens when you ignore time).

separation(lm_to_icrs(l, m, phase_centre, t0 + offset), lm_to_icrs(l, m, phase_centre, t0))

Notice, after exactly 1 year the difference is again minimal, because the Earth is (nearly) in the same spot. The peak error is reached around 6 months.

Here's the error v.s. sqrt(l^2 + m^2) over the course of a year's offset.

Of course, as is usual, for narrow fields of view it's negligible. But, for wide field of view it's good to take into account, and not too hard either.

[landmanbester]

Of course, as is usual, for narrow fields of view it's negligible. But, for wide field of view it's good to take into account, and not too hard either.

Yup we definitely need this for VLBI but quite low on the priority list for MeerKAT. Would you consider making a PR @Joshuaalbert ?

[Joshuaalbert]

I can share the code once I publish the DSA code repo

[bennahugo]

I agree this is a bug that needs squashing -- if I understand the whole problem correctly the ra and dec needs to be in the 'now' J20xx epoch (ie. taking into account both topocentric -> heliocentric and precession effects). This should be reasonably simple to ask something like astropy to do a heliocentric conversion on the specified coordinates I do want to point out though that both l and m are functions of ra and dec, not just a single coordinate at pointed out, see AIPS memo 27. It also depends which map projection you are using - it could be a cutting projection. For now everything is coded up assuming the SIN projection.

…

On Thu, Apr 11, 2024 at 7:15 PM Joshua George Albert < ***@***.***> wrote: I can share the code once I publish the DSA code repo — Reply to this email directly, view it on GitHub <#305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4RE6WKRNRDBOKRCIZBW53Y43AKXAVCNFSM6AAAAABGAZQC26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJQGE2DOOJUGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- -- Benjamin Hugo

[bennahugo]

I see ICRS is barycentric not heliocentric. Sorry. Am I correct in saying that we need to go from (edit ICRS -> GCRS -> spherical cosines [for projection onto a geocentric uvw basis]). I should note that I don't think any of the imaging software actually does this, but it is something I should be doing for TART (not that it matters at the current resolution though!)

[ludwigschwardt]

The major effect of aberration on the image plane is a uniform scaling (up to 1 ± 1e-4 for annual aberration). This would be taken care of in the UVW calculations if UVW is based on delay differentials like in CALC - an upgrade I still plan for katpoint this year. The effect on MeerKAT images are tiny (shifts much less than a pixel width).

Here is a nice exaggerated representation of what your image plane does over a year (courtesy of @bmerry) to give your stomach some aberration 😂

💡 Come to think of it, maybe this explains why CALC sometimes calculates (u, v) coordinates without aberration, something I've always wondered about... Then the lmn coordinates can incorporate that, since (u, v) can only correct linear scaling and rotation around the phase centre and not non-linear warping far away from the phase centre. That would be easier to fix in lmn space 🤔

[landmanbester]

an upgrade I still plan for katpoint this year.

Does this upgrade also include documentation? 😉

[Joshuaalbert]

Nice visual! The UV coordinates in the precise formulation are as u=d/dl phi, v=d/dm phi where phi is a delay function including motion of the observer relative to inertial reference frame, and the gravitational potential of the antennas. There was a paper somewhere I read on it once, but can't find now. But, anyways this gives rise to a nice definition for u,v. I think l,m are inversely defined as l=d/du (phi/2pi) and m=d/dv (phi/2pi), so that in the simple case when phi = 2 pi (u*l + v*m) we recover the expected results. Things like motion and gravity alter the form of phi giving more terms and denominators, etc.

So I think even if the u,v coordinates taking into account aberration, the calculation of l,m needs to as well.

[Joshuaalbert]

Interesting comparison of UVW computations btw: https://colab.research.google.com/github/casangi/radio_telescope_delay_model/blob/main/example_notebooks/Radio_Telescope_Delay_Model_Example.ipynb

[ludwigschwardt]

Thanks Joshua! I followed your attempts to add UVW to Astropy (astropy/astropy#6882, astropy/astropy#9869, astropy/astropy#10737) with great interest in the past. I also maintain yet another CALC wrapper. I'd love to continue this conversation once I hit the katpoint UVW code again 😁