Skip to content

Create InterferometricVisibility frame #7766

Open

Description

@mhvk

An attempt was made in #6882, but that may have been incomplete - see #6882 (comment) in particular

Activity

  1. adrn commented on Aug 24, 2018

    @adrn
    Member

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

  2. jwoillez commented on Aug 27, 2018

    @jwoillez
    Member

    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?

  3. mhvk commented on Aug 27, 2018

    @mhvk
    ContributorAuthor

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

  4. adrn commented on Aug 28, 2018

    @adrn
    Member

    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.

  5. changed the title [-]Create radio UVW frame[/-] [+]Create InterferometryUVW frame[/+] on Aug 28, 2018
  6. mhvk commented on Aug 28, 2018

    @mhvk
    ContributorAuthor

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

  7. changed the title [-]Create InterferometryUVW frame[/-] [+]Create InterferometricUVW frame[/+] on Aug 29, 2018
  8. eteq commented on Aug 29, 2018

    @eteq
    Member

    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)

  9. cmurray-astro commented on Sep 4, 2018

    @cmurray-astro

    As the UVW coordinate system for interferometers is used to describe complex visibilities, how about InterferometricVisibility?

  10. eteq commented on Oct 1, 2018

    @eteq
    Member

    I like InterferometricVisibility - agree, @adrn and @mhvk?

  11. changed the title [-]Create InterferometricUVW frame[/-] [+]Create InterferometricVisibility frame[/+] on Oct 1, 2018
  12. Joshuaalbert commented on May 20, 2019

    @Joshuaalbert

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

  13. Joshuaalbert commented on Sep 16, 2020

    @Joshuaalbert

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

  14. mhvk commented on Jun 19, 2024

    @mhvk
    ContributorAuthor

    In #10737 (comment), @Joshuaalbert wrote

    @caseyjlaw I have written a JAX+astropy based VLBI-accurate UVW engine here https://github.com/Joshuaalbert/DSA2000-Cal/blob/main/dsa2000_cal/dsa2000_cal/common/uvw_utils.py for the DSA2000 project and wonder if there is any desire still to have this functionality in astropy. #9869

    Further relevant conversation:

    Definitely still would like to have UVW in astropy (though not a dependency on JAX; is it optional?)

    This is the core part that relies on auto diff https://github.com/Joshuaalbert/DSA2000-Cal/blob/4dfd9d2d85c215850de2ef01fc6efef940f3ce7f/dsa2000_cal/dsa2000_cal/common/uvw_utils.py#L312

  15. Joshuaalbert commented on Aug 2, 2024

    @Joshuaalbert

    @mhvk a few questions are needed to assert the accuracy of this implementation, based on astropy coordinates.

    1. to what accuracy is the transform to/from GCRS to Barycentric coordinates performed in astropy? 1mm would be using:
    r_bcrs = r_gcrs (1 - U_earth/c^2) - 1/2 (V_earth_bcrs . r_gcrs) V_earth_bcrs
    

    Can you point me the right documentation, or code? Is there a way to control this accuracy?

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

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

  16. mhvk commented on Aug 2, 2024

    @mhvk
    ContributorAuthor

    @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

    def icrs_to_gcrs(icrs_coo, gcrs_frame):

    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 epv00 or 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

    def aticq(srepr, astrom):

    And apcs is wrapped at

    def apcs(frame_or_coord):
    """
    Wrapper for ``erfa.apcs``, used in conversions GCRS <-> ICRS.
    Parameters
    ----------
    frame_or_coord : ``astropy.coordinates.BaseCoordinateFrame`` or ``astropy.coordinates.SkyCoord``
    Frame or coordinate instance in the corresponding frame
    for which to calculate the calculate the astrom values.
    For this function, a GCRS frame is expected.
    """
    jd1_tt, jd2_tt = get_jd12(frame_or_coord.obstime, "tt")
    obs_pv = pav2pv(
    frame_or_coord.obsgeoloc.get_xyz(xyz_axis=-1).value,
    frame_or_coord.obsgeovel.get_xyz(xyz_axis=-1).value,
    )
    earth_pv, earth_heliocentric = prepare_earth_position_vel(
    frame_or_coord.obstime
    )
    return erfa.apcs(jd1_tt, jd2_tt, obs_pv, earth_pv, earth_heliocentric)

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

  17. Joshuaalbert commented on Aug 2, 2024

    @Joshuaalbert

    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.

  18. mhvk commented on Aug 3, 2024

    @mhvk
    ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions