Reference frames - poliastro/poliastro GitHub Wiki
First exploration
Material
- The documents that define the standards (IAU resolutions, IERS conventions) are too technical for the casual user.
- There is not much introductory material on reference frames freely available on the Internet.
- The best explanatory resource is the USNO Circular 179 (see links). Technical, but manageable.
Small bodies coordinates
- The Small-Body Database Browser ("the Browser") gives this hint for the reference frames: "Orbital Elements at Epoch 2458000.5 (2017-Sep-04.0) TDB -- Reference: JPL 611 (heliocentric ecliptic J2000)" (example for Eros, SPK ID 2000433)
- There are no references whatsoever on what does "JPL 611" mean, and each body has a different number (but same note: "heliocentric ecliptic J2000")
- The results given by the NeoWS REST API ("the API") match exactly the ones obtained in the Browser.
- The results given by Horizons for the same body, centered in the Sun (500@10), computed in ICRF/J2000.0 and "ecliptic and mean equinox of reference epoch" resemble, but do not match exactly, the ones given by the Browser, even for the same epoch.
- There is therefore an ambiguity on which reference frame does the Browser use. Although it could be a difference between mean and true equinox, there is no way to know since Horizons does not allow true equinox computations. It can also be that the data sources are simply different, and that Horizons and the Browser use different orbit determination methods.
- As a result, it is not clear whether the
HeliocentricTrueEcliptic
reference frame available inastropy.coordinates
can be used for coordinates obtained by the Browser or the API. - However, the discussion regarding the implementation of ecliptic coordinates in Astropy (see https://github.com/astropy/astropy/pull/3749) already admits that there is a lack of authoritative definitions and good test cases.
- In conclusion, it might be safe to use it, until someone with more knowledge says otherwise.
Planetary reference frames
- The planetary reference frames are useful since we can study spacecraft orbiting other bodies of the Solar System.
- The definitions are given in the "Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements" with respect to ICRS.
Proposal
The idea is to first provide "low level functions" that operate directly on position and velocity vectors, without using any high-level representation (see alternatives below).
def icrs_to_body_centered(r, v, target_body, epoch=None, rotate_meridian=False):
"""Converts position and velocity in ICRS to body-centered frame.
Parameters
----------
r : ~astropy.units.Quantity
Position vector in ICRS.
v : ~astropy.units.Quantity
Velocity vector in ICRS.
target_body : Body
Target body.
epoch : ~astropy.time.Time, optional
Epoch, default to J2000.
rotate_meridian : bool, optional
Whether to apply the rotation of the meridian too, default to False.
Returns
-------
r : ~astropy.units.Quantity
Position vector in a body-centered reference frame.
v : ~astropy.units.Quantity
Velocity vector in a body-centered reference frame.
"""
pass
def body_centered_to_icrs(r, v, source_body, rotate_meridian=False):
"""Converts position and velocity body-centered frame to ICRS.
Parameters
----------
r : ~astropy.units.Quantity
Position vector in a body-centered reference frame.
v : ~astropy.units.Quantity
Velocity vector in a body-centered reference frame.
source_body : Body
Source body.
epoch : ~astropy.time.Time, optional
Epoch, default to J2000.
rotate_meridian : bool, optional
Whether to apply the rotation of the meridian too, default to False.
Returns
-------
r : ~astropy.units.Quantity
Position vector in ICRS.
v : ~astropy.units.Quantity
Velocity vector in ICRS.
"""
pass
Missing
Lots of notes and documentation will be needed here. In particular:
- What is ICRS (brief description, and link to corresponding IAU resolution)
- Distinction between barycenter and body center in ephemerides
- Links to the corresponding IAU Working Group documents, see below
- Why the non-rotated frames are tested and the others are not
- Others?
Alternatives
Orbit
objects as input/output to consolidate body, position, velocity and epoch?
Why not using It would be nice to do it that way, but it is not clear what to return when using a non-inertial frame since the conversion to orbital elements loses its meaning.
BaseRepresentation
objects from Astropy?
Why not using The differentials implementation is still considered experimental and subject to change.
BaseCoordinateFrame
objects from Astropy?
Why not using Same reason as above, plus some concerns regarding underlying inner workings [TODO: Expand]
Links
- USNO Circular 179 http://aa.usno.navy.mil/publications/docs/Circular_179.pdf
- ICATT 2010 Workshop http://trajectory.estec.esa.int/Astro/4rth-astro-workshop-presentations/ICATT-2010-Tutorial-ASTRODYNAMICS.pdf
- SOFA Tools for Earth Attitude http://www.iausofa.org/sofa_pn_c.pdf
- IERS Conventions 2010 https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html?nn=94912
- JPL HORIZONS https://ssd.jpl.nasa.gov/horizons.cgi
- JPL Small-Body Database Broswer https://ssd.jpl.nasa.gov/sbdb.cgi