New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace ephemerides functions with Astropy equivalents #131

Closed
Juanlu001 opened this Issue Aug 7, 2016 · 7 comments

Comments

1 participant
@Juanlu001
Member

Juanlu001 commented Aug 7, 2016

This replacement cannot be done until Astropy supports proper motions and velocities, see this bug:

astropy/astropy#4344

For instance, get_body_barycentric does not return the velocity of the planets, and therefore it's useless for our purposes.

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Aug 16, 2016

First steps: barycentric velocities in Astropy astropy/astropy#5231

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Dec 26, 2016

@Juanlu001 Juanlu001 modified the milestone: Future Feb 12, 2017

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Feb 26, 2017

Using the class CartesianRepresentation is needed for vector arithmetic, but it doesn't work with normal Quantity objects for obvious reasons.

@Juanlu001 Juanlu001 modified the milestones: 0.7, Future Feb 26, 2017

@Juanlu001 Juanlu001 added the 1 - Ready label Feb 26, 2017

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Feb 26, 2017

For some reason I'm not getting the same results with poliastro and the jpl ephemeris of Astropy. More debugging required.

In [1]: from poliastro.ephem import planet_ephem

In [2]: from astropy.time import Time

In [5]: from poliastro.ephem import EARTH

In [6]: t = Time("2014-09-22 23:22")

In [7]: planet_ephem(EARTH, t)
Out[7]: 
(<Quantity [  1.50492843e+08, -9.68589576e+05, -4.41002632e+05] km>,
 <Quantity [  -26318.45001712, 2353112.69264584, 1020089.67574404] km / d>)

In [8]: from astropy.coordinates import solar_system_ephemeris

In [9]: solar_system_ephemeris.set("jpl")
Downloading http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/de430.bsp
|=====================================================================================| 119M/119M (100.00%)      1m21s
Out[9]: <ScienceState solar_system_ephemeris: 'jpl'>

In [10]: print(solar_system_ephemeris.bodies)
('sun', 'mercury', 'venus', 'earth-moon-barycenter', 'earth', 'moon', 'mars', 'jupiter', 'saturn', 'uranus', 'neptune', 'pluto')

In [11]: from astropy.coordinates import get_body_barycentric_posvel

In [12]: get_body_barycentric_posvel("earth", t)
Out[12]: 
(<CartesianRepresentation (x, y, z) in km
     (  1.50497562e+08, -967989.50119331, -440470.76265497)>,
 <CartesianRepresentation (x, y, z) in km / d
     (-26112.51286015,  2354057.67909512,  1020412.96649401)>)

In [13]: get_body_barycentric_posvel("earth-moon-barycenter", t)
Out[13]: 
(<CartesianRepresentation (x, y, z) in km
     (  1.50492823e+08, -966759.85640148, -440209.43710451)>,
 <CartesianRepresentation (x, y, z) in km / d
     (-26352.62592805,  2353112.87308378,  1020089.75407521)>)
@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Feb 26, 2017

Reason: it's using TDB scale in the background, see https://github.com/astropy/astropy/blob/v1.3/astropy/coordinates/solar_system.py#L218

In [28]: list(solar_system_ephemeris.kernel[0, 3].generate(t.jd1, t.jd2))
Out[28]: 
[array([  1.50492843e+08,  -9.68589576e+05,  -4.41002632e+05]),
 array([  -26318.45001712,  2353112.69264584,  1020089.67574404])]

In [29]: t.scale
Out[29]: 'utc'

In [30]: t.utc
Out[30]: <Time object: scale='utc' format='iso' value=2014-09-22 23:22:00.000>

In [31]: t.utc.jd2
Out[31]: 0.9736111111111111

In [32]: t.tdb.jd2
Out[32]: 0.9743886852002873

In [33]: list(solar_system_ephemeris.kernel[0, 3].generate(t.tdb.jd1, t.tdb.jd2))
Out[33]: 
[array([  1.50492823e+08,  -9.66759856e+05,  -4.40209437e+05]),
 array([  -26352.62592805,  2353112.87308378,  1020089.75407521])]
@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Feb 26, 2017

Quoting the original report:

The coordinate time scale used for DE430 and DE431 is Barycentric Dynamical Time (TDB)
as defined in terms of Barycentric Coordinate Time (TCB).

http://ipnpr.jpl.nasa.gov/progress_report/42-196/196C.pdf

Therefore, poliastro has been almost correct, but wrong, since #42 was merged. I'm tagging this as a bug.

@Juanlu001 Juanlu001 added bug help wanted and removed enhancement labels Feb 26, 2017

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Feb 26, 2017

After this change, we might want to add regression tests with strong tolerance checks. Idea: parametrize the tolerance locally so we can try a range of possible values and easily see the lowest one that fulfills the requirements.

Juanlu001 added a commit to Juanlu001/poliastro that referenced this issue Mar 11, 2017

WIP: Add 3D interactivity to Mars example
Also replace ephemerides functions, still there is some boilerplate
involved. We will probably need to wrap Astropy here, see poliastro#131 for
future work.

@Juanlu001 Juanlu001 closed this in e353c4e Mar 20, 2017

@wafflebot wafflebot bot removed the 1 - Ready label Mar 20, 2017

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