You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just to re-raise my comment from #6882 with a suggestion: perhaps we could name the frame something like RadioUVW to distinguish it from the Galactic velocity components (also UVW)?
This frame would also be used with optical interferometers. Why not call it InterferometricUVW if the confusion with Galactic velocity components is really a problem? Though, a frame being first about positions, is there any chance of having a UVW frame that relates to Galactic velocity components?
@adrn - I'd agree with @jwoillez that confusion would seem rather unlikely, given that in galactic coordinates u, v, and w are velocities. Anyway, better first have an actual PR to work from...
The point is that to a new user of Astropy, or to a student, the name overloading is confusing. It wouldn't hurt to be a bit more specific in the name to be sensitive to this. And FWIW, u, v, w are used as positional coordinates in the Galactic frame, whereas U, V, W are the corresponding velocities.
@adrn - OK, I see, it is the cartesian representation of Galactic you are worried about. So, let's aim for InterferometricUVW (unless a better name appears); I've changed the title accordingly.
What about just Interferometric? That actually seems cleaner to me - after all we don't call it GalacticUVW or even GalacticLatLon... Really AltAz is the only one with the names (and that's already gotten us into trouble... see #7708)
@mhvk If you want to still implement this, I have a reference that will speed things up. The Event Horizon Telescope (VLBI) calculates their UV coordinates here. They only define the U and V coordinates, and the W can be found easily using projU and projV in that source as projW = eye(3) - projU - projV. However, I feel there is actually an easier and more robust way to do UVW with astropy's builtin coords.
Also, I'm not 100% certain the EHT's implementation is correct. I don't think it takes into account the motion of the observer which is different for antennas in different places on Earth.
@caseyjlaw I found a good person to bring in, who will help get this implemented properly. Frits (@tikk3r) is a PhD student working with LOFAR including the international baselines. We don't call it VLBI because the baselines are only a few 1000km but it's still in the realm of VLBI. Anyways, Frits offers his attention to this. I think we can get it going in a few weeks. @tikk3rthis is the PR related to it and we'll do our conversation there.
Can you point me the right documentation, or code? Is there a way to control this accuracy?
Are the GCRS coordinates Terrestrial Time (TT) compatible i.e. linearly scaled so that time matches the rate of proper time on the geoid (the rate that atomic clocks would tick at stations on the Earth's surface)? Or are the geocentric coordinate time (TCG)?
Are the BCRS coordinates (i.e. ICRS) barycentric dynamical time (TDB) compatible? or barycentric coordinate time (TCB) compatible?
2 and 3 are important because depending on the convention used in astropy the coordinates may require a scaling to be correct at the VLBI level.
@Joshuaalbert - I'm not 100% sure I understand what your r are for; the observer or the source?
Anyway, probably good to lay out the basics regardless: astropy internally uses SOFA routines (via ERFA). Note that we still do not have a proper BCRS, but the GCRS<->ICRS transformations are at
It seems that we pass in "TT" instead of the nominally required "TBD", though the apcs documentation states "TT can be used instead of TDB without any significant impact on accuracy." This may need to (and can) be revisted...
Thank you for the in-depth reply. So I found "ICRS to GCRS covers space motion, parallax, light deflection, and aberration. " Which is probably good to s few ps accuracy in delay modelling but I'll work on verifying this. What would be kind of cool is to have an option to control how precise to make the delay calculation.
Agreed - I'm actually not quite sure sure still where that is done! But absolutely fine with changing things around (and try to get it upstream to SOFA if relevant).
Activity
adrn commentedon Aug 24, 2018
Just to re-raise my comment from #6882 with a suggestion: perhaps we could name the frame something like
RadioUVWto distinguish it from the Galactic velocity components (also UVW)?jwoillez commentedon Aug 27, 2018
This frame would also be used with optical interferometers. Why not call it
InterferometricUVWif the confusion with Galactic velocity components is really a problem? Though, a frame being first about positions, is there any chance of having a UVW frame that relates to Galactic velocity components?mhvk commentedon Aug 27, 2018
@adrn - I'd agree with @jwoillez that confusion would seem rather unlikely, given that in galactic coordinates u, v, and w are velocities. Anyway, better first have an actual PR to work from...
adrn commentedon Aug 28, 2018
The point is that to a new user of Astropy, or to a student, the name overloading is confusing. It wouldn't hurt to be a bit more specific in the name to be sensitive to this. And FWIW,
u, v, ware used as positional coordinates in the Galactic frame, whereasU, V, Ware the corresponding velocities.[-]Create radio UVW frame[/-][+]Create InterferometryUVW frame[/+]mhvk commentedon Aug 28, 2018
@adrn - OK, I see, it is the cartesian representation of
Galacticyou are worried about. So, let's aim forInterferometricUVW(unless a better name appears); I've changed the title accordingly.[-]Create InterferometryUVW frame[/-][+]Create InterferometricUVW frame[/+]eteq commentedon Aug 29, 2018
What about just
Interferometric? That actually seems cleaner to me - after all we don't call itGalacticUVWor evenGalacticLatLon... ReallyAltAzis the only one with the names (and that's already gotten us into trouble... see #7708)cmurray-astro commentedon Sep 4, 2018
As the UVW coordinate system for interferometers is used to describe complex visibilities, how about
InterferometricVisibility?eteq commentedon Oct 1, 2018
I like
InterferometricVisibility- agree, @adrn and @mhvk?[-]Create InterferometricUVW frame[/-][+]Create InterferometricVisibility frame[/+]Joshuaalbert commentedon May 20, 2019
@mhvk If you want to still implement this, I have a reference that will speed things up. The Event Horizon Telescope (VLBI) calculates their UV coordinates here. They only define the U and V coordinates, and the W can be found easily using projU and projV in that source as
projW = eye(3) - projU - projV. However, I feel there is actually an easier and more robust way to do UVW with astropy's builtin coords.Also, I'm not 100% certain the EHT's implementation is correct. I don't think it takes into account the motion of the observer which is different for antennas in different places on Earth.
Joshuaalbert commentedon Sep 16, 2020
@caseyjlaw I found a good person to bring in, who will help get this implemented properly. Frits (@tikk3r) is a PhD student working with LOFAR including the international baselines. We don't call it VLBI because the baselines are only a few 1000km but it's still in the realm of VLBI. Anyways, Frits offers his attention to this. I think we can get it going in a few weeks. @tikk3r this is the PR related to it and we'll do our conversation there.
EDIT: that PR is dead and I'll make a new one.
mhvk commentedon Jun 19, 2024
In #10737 (comment), @Joshuaalbert wrote
Further relevant conversation:
Joshuaalbert commentedon Aug 2, 2024
@mhvk a few questions are needed to assert the accuracy of this implementation, based on astropy coordinates.
Can you point me the right documentation, or code? Is there a way to control this accuracy?
Are the GCRS coordinates Terrestrial Time (TT) compatible i.e. linearly scaled so that time matches the rate of proper time on the geoid (the rate that atomic clocks would tick at stations on the Earth's surface)? Or are the geocentric coordinate time (TCG)?
Are the BCRS coordinates (i.e. ICRS) barycentric dynamical time (TDB) compatible? or barycentric coordinate time (TCB) compatible?
2 and 3 are important because depending on the convention used in astropy the coordinates may require a scaling to be correct at the VLBI level.
mhvk commentedon Aug 2, 2024
@Joshuaalbert - I'm not 100% sure I understand what your
rare for; the observer or the source?Anyway, probably good to lay out the basics regardless: astropy internally uses SOFA routines (via ERFA). Note that we still do not have a proper BCRS, but the GCRS<->ICRS transformations are at
astropy/astropy/coordinates/builtin_frames/icrs_cirs_transforms.py
Line 115 in 384e90b
The basic idea is that we use https://pyerfa.readthedocs.io/en/latest/api/erfa.atciq.html and https://pyerfa.readthedocs.io/en/latest/api/erfa.atciqz.html with the astrometric parameters prefilled by https://pyerfa.readthedocs.io/en/latest/api/erfa.apcs.html (and Earth position/velocity either from built-in
epv00or JPL ephemerides). The parallax shift is done "by hand".However, of course there are details. In reality we use slightly modified versions (for light bending near Sun); starting at
astropy/astropy/coordinates/builtin_frames/utils.py
Line 169 in 384e90b
And
apcsis wrapped atastropy/astropy/coordinates/erfa_astrom.py
Lines 93 to 112 in 384e90b
It seems that we pass in "TT" instead of the nominally required "TBD", though the apcs documentation states "TT can be used instead of TDB without any significant impact on accuracy." This may need to (and can) be revisted...
Joshuaalbert commentedon Aug 2, 2024
Thank you for the in-depth reply. So I found "ICRS to GCRS covers space motion, parallax, light deflection, and aberration. " Which is probably good to s few ps accuracy in delay modelling but I'll work on verifying this. What would be kind of cool is to have an option to control how precise to make the delay calculation.
mhvk commentedon Aug 3, 2024
Agreed - I'm actually not quite sure sure still where that is done! But absolutely fine with changing things around (and try to get it upstream to SOFA if relevant).