JPL Horizons elements query fails for planets, i.e. 'majorbody'

[SolSysMiner]

This query worked last week, now it fails. This issue may have been triggered by last Monday's update on the SSD site.

`from astroquery.jplhorizons import Horizons

obj = Horizons(id='399', location='500@10', epochs=2458133.33546, id_type='majorbody')

el = obj.elements()

print(el)`

Error message:

Traceback (most recent call last): File ".../testERROR.py", line 14, in el = obj.elements() File "/usr/lib64/python3.9/site-packages/astroquery/utils/class_or_instance.py", line 25, in f return self.fn(obj, *args, **kwds) File "/usr/lib64/python3.9/site-packages/astroquery/utils/process_asyncs.py", line 29, in newmethod result = self._parse_result(response, verbose=verbose) File "/usr/lib64/python3.9/site-packages/astroquery/jplhorizons/core.py", line 1296, in _parse_result data = self._parse_horizons(response.text) File "/usr/lib64/python3.9/site-packages/astroquery/jplhorizons/core.py", line 1188, in _parse_horizons raise ValueError(('Query failed without known error message; ' ValueError: Query failed without known error message; received the following response:

---

Revised: April 12, 2021 Earth 399

GEOPHYSICAL PROPERTIES (revised Aug 15, 2018): Vol. Mean Radius (km) = 6371.01+-0.02 Mass x10^24 (kg)= 5.97219+-0.0006 Equ. radius, km = 6378.137 Mass layers: Polar axis, km = 6356.752 Atmos = 5.1 x 10^18 kg Flattening = 1/298.257223563 oceans = 1.4 x 10^21 kg Density, g/cm^3 = 5.51 crust = 2.6 x 10^22 kg J2 (IERS 2010) = 0.00108262545 mantle = 4.043 x 10^24 kg g_p, m/s^2 (polar) = 9.8321863685 outer core = 1.835 x 10^24 kg g_e, m/s^2 (equatorial) = 9.7803267715 inner core = 9.675 x 10^22 kg g_o, m/s^2 = 9.82022 Fluid core rad = 3480 km GM, km^3/s^2 = 398600.435436 Inner core rad = 1215 km GM 1-sigma, km^3/s^2 = 0.0014 Escape velocity = 11.186 km/s Rot. Rate (rad/s) = 0.00007292115 Surface area: Mean sidereal day, hr = 23.9344695944 land = 1.48 x 10^8 km Mean solar day 2000.0, s = 86400.002 sea = 3.62 x 10^8 km Mean solar day 1820.0, s = 86400.0 Love no., k2 = 0.299 Moment of inertia = 0.3308 Atm. pressure = 1.0 bar Mean temperature, K = 270 Volume, km^3 = 1.08321 x 10^12 Mean effect. IR temp, K = 255 Magnetic moment = 0.61 gauss Rp^3 Geometric albedo = 0.367 Vis. mag. V(1,0)= -3.86 Solar Constant (W/m^2) = 1367.6 (mean), 1414 (perihelion), 1322 (aphelion) HELIOCENTRIC ORBIT CHARACTERISTICS: Obliquity to orbit, deg = 23.4392911 Sidereal orb period = 1.0000174 y Orbital speed, km/s = 29.79 Sidereal orb period = 365.25636 d Mean daily motion, deg/d = 0.9856474 Hill's sphere radius = 234.9

---

Cannot output osculating elements of a SURFACE LOCATION wrt another object.

!$$SOF TABLE_TYPE = ELEMENTS MAKE_EPHEM = YES OUT_UNITS = AU-D COMMAND = "399" CENTER = '500@10' CSV_FORMAT = YES ELEM_LABELS = YES OBJ_DATA = YES REF_SYSTEM = J2000 REF_PLANE = ECLIPTIC TP_TYPE = ABSOLUTE TLIST = 2458133.33546

[bsipocz]

The underlying API has been changed on the Horizons side, and during our refactor we have moved the behaviour of astroquery closer to the web interface. So, please note majorbody is not a supported id_type any more.

Also, checking your query, I get the same "Cannot output osculating elements of a SURFACE LOCATION wrt another object." response from the server, even when forcing it to use the old API, so you may want to rephrase the specifics.

[bsipocz]

cc @mkelley in case you spot something I missed.

[SolSysMiner]

Thanks for your quick reply. Yes, I am aware that the same issue emerges when using the actual interface and I told them about it. It looks like the server side engine believes that a location on the surface of the planet is being used when the "elements" section does not need any as the center of the planet is the location. The parameter value 'majorbody' is still being used and it works for moons. This issue may have been triggered by last Monday's update on the SSD site.

[bsipocz]

If you upgrade to the latest version (use --pre as only the dev version has been deployed), then you will get a warning when using the value majorbody and it'll default back to the default behaviour of the server-side. (More details https://github.com/astropy/astroquery/pull/2161).

[SolSysMiner]

I did "pip install --pre -u astroquery". Virtually same outcome. By the way, I did not get any reply from JPL and they usually provide prompt and helpful assistance.

[bsipocz]

OK, please do keep us updated if you hear back.

[SolSysMiner]

Thanks, I will do. Many automated scripts may be failing since this issue emerged (ours are). I do not think they will remove the 'majorbody' value as it is used not only for planets but also for natural satellites, and this was working OK until last Sunday (CEST) for sure. We detected the issue on Monday, did some testing on Monday and Tuesday to no avail. Sent them word of it yesterday.

[mkelley]

I don't usually run these queries, but I can at least add another confirmation of the behavior and that the web interface reports the same error. As far as I understand the documentation (and celestial mechanics), this should be allowed.

[SolSysMiner]

Thanks for confirming. This is the exact screenshot I sent to JPL. This was not the output you could get last Sunday. We are now certain that this issue is not something resulting from an astroquery update but from a change made to the Horizons engine v4.90. Using the old telnet interface (telnet ssd.jpl.nasa.gov 6775) and entering MB at the prompt, everything seems to be the way it was, so I have tried a slightly different approach:

`from astroquery.jplhorizons import Horizons

obj = Horizons(id='399', location='10', epochs=2458133.33546, id_type='majorbody')

el = obj.elements()

print(el)`

and it seems to work fine:

targetname datetime_jd datetime_str ... a Q P
--- d --- ... AU AU d
----------- ------------- ------------------------------ ... ----------------- ----------------- ----------------- Earth (399) 2458133.33546 A.D. 2018-Jan-14 20:03:03.7440 ... 1.000773877602447 1.018220628351936 365.6804273878107

That seems to be about right. So instead of using the customary "@sun" or "500@10" as location, just "10" will do the heliocentric osculating orbital elements. However, if you use the same approach with the web interface, the "10" is translated into an actual location on the surface of our planet (Caussols (observatory) [code: 010]) so the issue may have multiple sub issues.

CRITICAL UPDATE:

I just got word from JPL indicating that the issue has been fixed in v4.90. A quick test using the web interface confirmed the good news and the python output is now:

targetname datetime_jd datetime_str ... a Q P
--- d --- ... AU AU d
----------- ------------- ------------------------------ ... ----------------- ----------------- ----------------- Earth (399) 2458133.33546 A.D. 2018-Jan-14 20:03:03.7440 ... 1.000773877602447 1.018220628351936 365.6804273878107 targetname datetime_jd datetime_str ... a Q P
--- d --- ... AU AU d
----------- ------------- ------------------------------ ... ----------------- ----------------- ----------------- Earth (399) 2458133.33546 A.D. 2018-Jan-14 20:03:03.7440 ... 1.000773877602447 1.018220628351936 365.6804273878107

when using

'obj = Horizons(id='399', location='500@10', epochs=2458133.33546, id_type='majorbody') el = obj.elements() print(el)

obj = Horizons(id='399', location='@sun', epochs=2458133.33546, id_type='majorbody') el = obj.elements() print(el)'

So this issue can be closed. Thanks Brigitta and Michael for your time. Astropy is truly a great tool!!