JPL Horizons: differing results between python and web output
See original GitHub issueI’m trying to get the RA/Dec of an asteroid from the position of a satellite. I have the satellite’s lat/lon/altitude, and I get the asteroid position from astroquery’s jpl horizons package. The results from my test script horizons_example.txt (change to .py) show that the asteroid should be at
FK5 (deg) RA Dec
vectors() : 244.665601 -21.016988
vectors(refplane=earth) : 244.665601 -21.016988
ephemerides() : 244.660500 -21.016170
but on the Horizons webpage, it says the asteroid RA/Dec should be:
269.91184 33.68373
The full web output is:
*******************************************************************************
JPL/HORIZONS (2020 CD3) 2021-Sep-27 15:53:02
Rec #:50504613 (+COV) Soln.date: 2021-Jun-25_15:07:42 # obs: 128 (2018-2020)
IAU76/J2000 helio. ecliptic osc. elements (au, days, deg., period=Julian yrs):
EPOCH= 2458914.5 ! 2020-Mar-06.00 (TDB) Residual RMS= .078773
EC= .03494529757096312 QR= .9863971818171792 TP= 2458866.3996462021
OM= 134.7432090092998 W= 342.2597100247675 IN= .7388576324362984
A= 1.022115305313184 MA= 45.87779192987005 ADIST= 1.057833428809189
PER= 1.03338 N= .9537932059999999 ANGMOM= .017380651
DAN= .98798 DDN= 1.05602 L= 117.0043116
B= -.2251263 MOID= .00224417 TP= 2020-Jan-17.8996462021
Asteroid physical parameters (km, seconds, rotational period in hours):
GM= n.a. RAD= n.a. ROTPER= n.a.
H= 31.8 G= .150 B-V= n.a.
ALBEDO= n.a. STYP= n.a.
Asteroid non-gravitational force model (AMRAT= m^2/kg;A1,A2,A3=au/d^2;R0=au):
AMRAT= 0.
A1= 1.356929074973E-10 A2= 0. A3= 0.
Non-standard or simulated/proxy model:
ALN= 1. NK= 0. NM= 2. NN= 0. R0= 1.
ASTEROID comments:
1: soln ref.= JPL#27, OCC=0
2: source=ORB
*******************************************************************************
*******************************************************************************
Ephemeris / API_USER Mon Sep 27 15:53:02 2021 Pasadena, USA / Horizons
*******************************************************************************
Target body name: (2020 CD3) {source: JPL#27}
Center body name: Earth (399) {source: DE441}
Center-site name: (user defined site below)
*******************************************************************************
Start time : A.D. 2015-May-28 00:27:00.0000 UT
Stop time : A.D. 2015-May-28 04:27:00.0000 UT
Step-size : 60 minutes
*******************************************************************************
Target pole/equ : No model available
Target radii : (unavailable)
Center geodetic : 181.313736,0.23705460,539.14944 {E-lon(deg),Lat(deg),Alt(km)}
Center cylindric: 181.313736,6917.22760,28.442729 {E-lon(deg),Dxy(km),Dz(km)}
Center pole/equ : High-precision EOP model {East-longitude positive}
Center radii : 6378.1 x 6378.1 x 6356.8 km {Equator, meridian, pole}
Target primary : Sun
Vis. interferer : MOON (R_eq= 1737.400) km {source: DE441}
Rel. light bend : Sun, EARTH {source: DE441}
Rel. lght bnd GM: 1.3271E+11, 3.9860E+05 km^3/s^2
Small-body perts: Yes {source: SB441-N16}
Atmos refraction: NO (AIRLESS)
RA format : DEG
Time format : CAL
EOP file : eop.210926.p211220
EOP coverage : DATA-BASED 1962-JAN-20 TO 2021-SEP-26. PREDICTS-> 2021-DEC-19
Units conversion: 1 au= 149597870.700 km, c= 299792.458 km/s, 1 day= 86400.0 s
Table cut-offs 1: Elevation (-90.0deg=NO ),Airmass (>38.000=NO), Daylight (NO )
Table cut-offs 2: Solar elongation ( 0.0,180.0=NO ),Local Hour Angle( 0.0=NO )
Table cut-offs 3: RA/DEC angular rate ( 0.0=NO )
*******************************************************************************
Initial IAU76/J2000 heliocentric ecliptic osculating elements (au, days, deg.):
EPOCH= 2458914.5 ! 2020-Mar-06.00 (TDB) Residual RMS= .078773
EC= .03494529757096312 QR= .9863971818171792 TP= 2458866.3996462021
OM= 134.7432090092998 W= 342.2597100247675 IN= .7388576324362984
Equivalent ICRF heliocentric cartesian coordinates (au, au/d):
X=-9.675822914533228E-01 Y= 2.212974108216997E-01 Z= 1.031890496759188E-01
VX=-4.692966798948430E-03 VY=-1.547085528646655E-02 VZ=-6.494577482405959E-03
Asteroid physical parameters (km, seconds, rotational period in hours):
GM= n.a. RAD= n.a. ROTPER= n.a.
H= 31.8 G= .150 B-V= n.a.
ALBEDO= n.a. STYP= n.a.
Asteroid non-gravitational force model (AMRAT= m^2/kg;A1,A2,A3=au/d^2;R0=au):
AMRAT= 0.
A1= 1.356929074973E-10 A2= 0. A3= 0.
Non-standard or simulated/proxy model:
ALN= 1. NK= 0. NM= 2. NN= 0. R0= 1.
*******************************************************************************
Date__(UT)__HR:MN R.A.___(ICRF)___DEC
******************************************
$$SOE
2015-May-28 00:27 *m 269.91184 33.68373
2015-May-28 01:27 *m 269.95547 33.68764
2015-May-28 02:27 *m 269.99998 33.70396
2015-May-28 03:27 *m 270.03839 33.73238
2015-May-28 04:27 *m 270.06412 33.77181
$$EOE
*******************************************************************************
Column meaning:
TIME
Times PRIOR to 1962 are UT1, a mean-solar time closely related to the
prior but now-deprecated GMT. Times AFTER 1962 are in UTC, the current
civil or "wall-clock" time-scale. UTC is kept within 0.9 seconds of UT1
using integer leap-seconds for 1972 and later years.
Conversion from the internal Barycentric Dynamical Time (TDB) of solar
system dynamics to the non-uniform civil UT time-scale requested for output
has not been determined for UTC times after the next July or January 1st.
Therefore, the last known leap-second is used as a constant over future
intervals.
Time tags refer to the UT time-scale conversion from TDB on Earth
regardless of observer location within the solar system, although clock
rates may differ due to the local gravity field and no analog to "UT"
may be defined for that location.
Any 'b' symbol in the 1st-column denotes a B.C. date. First-column blank
(" ") denotes an A.D. date. Calendar dates prior to 1582-Oct-15 are in the
Julian calendar system. Later calendar dates are in the Gregorian system.
NOTE: "n.a." in output means quantity "not available" at the print-time.
SOLAR PRESENCE (OBSERVING SITE)
Time tag is followed by a blank, then a solar-presence symbol:
'*' Daylight (refracted solar upper-limb on or above apparent horizon)
'C' Civil twilight/dawn
'N' Nautical twilight/dawn
'A' Astronomical twilight/dawn
' ' Night OR geocentric ephemeris
LUNAR PRESENCE (OBSERVING SITE)
The solar-presence symbol is immediately followed by a lunar-presence symbol:
'm' Refracted upper-limb of Moon on or above apparent horizon
' ' Refracted upper-limb of Moon below apparent horizon OR geocentric
ephemeris
'R.A.___(ICRF)___DEC' =
Astrometric right ascension and declination of the target center with
respect to the observing site (coordinate origin) in the reference frame of
the planetary ephemeris (ICRF). Compensated for down-leg light-time delay
aberration.
Units: RA in decimal degrees, ddd.fffff{ffff}
DEC in decimal degrees, sdd.fffff{ffff}
Computations by ...
Solar System Dynamics Group, Horizons On-Line Ephemeris System
4800 Oak Grove Drive, Jet Propulsion Laboratory
Pasadena, CA 91109 USA
Information : https://ssd.jpl.nasa.gov/
Documentation: https://ssd.jpl.nasa.gov/?horizons_doc
Connect : https://ssd.jpl.nasa.gov/?horizons (browser)
telnet ssd.jpl.nasa.gov 6775 (command-line)
e-mail command interface available
Script and CGI interfaces available
Author : Jon.D.Giorgini@jpl.nasa.gov
*******************************************************************************
So, a) why is there such a large mismatch between the python and webpage RADecs? My first instinct is that I entered something incorrectly in the web interface, but I’m not sure. b) in the test script, why is the ephemerides() RADec different from the vectors() RADec?
Issue Analytics
- State:
- Created 2 years ago
- Comments:18 (7 by maintainers)
Top Results From Across the Web
Astroquery.jplhorizons output differs from Horizons webpage
I'm trying to get the RA/Dec of an asteroid from the position of a ... JPL Horizons: differing results between python and web...
Read more >Manual - Horizons System - NASA
The JPL Horizons on-line ephemeris system provides access to solar system data and customizable production of accurate ephemerides for observers, mission- ...
Read more >Overview - Astroquery
The HorizonsClass class provides an interface to services provided by the Solar System Dynamics group at the Jet Propulation Laboratory. Because of its ......
Read more >Discrepancy between HORIZONS and SPICE
I am trying to reproduce the output of the HORIZONS system using the SPICE toolkit from NASA, but I am not getting exactly...
Read more >Astropy and JPL's Horizons query have different output
I want to do this way because my purpose is to convert from geographic coordinates to heliocentric one. from astropy.coordinates import SkyCoord ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Here are my conclusions:
tim.tdb.jd
for the epoch, useepochs=[(tim - 4.036*units.s).tdb.jd]
.The output is then:
That is, the remaining discrepancy is ~0.1 arcsec.
It’s may be worth looking into any differences between the geodetic surface used by Astropy and the one used by HORIZONS.
Also, for asteroids this close to Earth, there may be a non-negligible inaccuracy in the small difference vector between two large vectors (with the SSB as the origin).