Skip to content

add util to fetch new orbit data elemets from JPL for ssystem_major, refs #4894#4908

Draft
schenlap wants to merge 7 commits into
Stellarium:masterfrom
schenlap:fetch_ssystem_major
Draft

add util to fetch new orbit data elemets from JPL for ssystem_major, refs #4894#4908
schenlap wants to merge 7 commits into
Stellarium:masterfrom
schenlap:fetch_ssystem_major

Conversation

@schenlap
Copy link
Copy Markdown
Contributor

@schenlap schenlap commented May 7, 2026

This is a continuation of pr #4894 , currently in draft state.

Description

I see this now fulfilled:

  • Update data with REF_PLANE=BODY,
  • check if ephemeris for 2026 with new data equals (at least almost) the JPL Horizon ephemeris, and if it is,
  • write the process in the SUG, subsubsection in Appendix D2.3.
  • Then maintainers can routinely update orbital elements of all minor moons every 1-2 years (or even automated per release checklist).
  • I would also like to see a description of the orbital model in the SUG. Do we know where the ascending node of the orbit against the planet equator is counted from? (It can hopefully be derived from the newer rotation model.)

That script should go into utils, and the process described in SUG and/or MAINTAINER_BUSINESS.md

Checklist:

  • My code follows the code style of this project.
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation (header file)
  • I have updated the respective chapter in the Stellarium User Guide
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@github-actions github-actions Bot requested review from 10110111, alex-w and gzotti May 7, 2026 18:46
@github-project-automation github-project-automation Bot moved this to Backlog in Solar System May 7, 2026
@alex-w alex-w added the data Missing/bad/outdated data, but no code error label May 7, 2026
@gzotti gzotti added this to the 26.2 milestone May 10, 2026
@gzotti gzotti moved this from Backlog to In progress in Solar System May 10, 2026
@schenlap
Copy link
Copy Markdown
Contributor Author

with
python3 compare_ssystem_major_JPL.py ../data/ssystem_major.ini himalia --max-error 30 --step 14
it is possible to compare all moons with JPL stellarium (currently 26.1).
result for location vienna:
ssystem_compare_26.1.pdf

I get small errors for moons of jupiter, saturn, uranus but I have big (nearly the same error) for neptun, mars an pluto moons. I have to investigate further.

image

@gzotti
Copy link
Copy Markdown
Member

gzotti commented May 10, 2026

Interesting work. I see some systematic parallels in 0.35' yearly amplitude, but then also in much larger parallel curves. Any light time effects? And clearly there is some error in the Moon evaluation, this should be within arcseconds or less, not up to 160° degrees off in monthly period. Is this a static Moon position?
Note that the large moons have their own models (not simple Kepler orbits) with which we can simulate mutual eclipses as observed by a few advanced amateurs, so this should qualify as "accurate". For the rest, yes, more to investigate.

@alex-w
Copy link
Copy Markdown
Member

alex-w commented May 11, 2026

JPL coordinates are topocentric or geocentric? Deimos and Phobos use special theories of orbits, but probably his out of valid range now.

@schenlap
Copy link
Copy Markdown
Contributor Author

I found my error. It was a radian to degree convertion that was unnecessary (claude.ai added it).
There is still an error that @gzotti mentioned. It looks the same for neptun, jupiter and saturn. Same amplitude, same frequency.

image

Now a few condidates are highlighted that clearly need correction with new data. I would suggest all with max error > 2' (maybe 0.35' came from the planet position itself).
image

JPL coordinates are topocentric or geocentric?

coord@399 + COORD_TYPE=GEODETIC + SITE_COORD = Topocentric (surface point)
I think there is a light missmatch in observer altitude, which is MSL in stellarium und WGT in JPL. In vienna the diff is around 46m. Adding this does not change the error. It is probably negligible.

@schenlap
Copy link
Copy Markdown
Contributor Author

schenlap commented May 11, 2026

when setting
flag_light_travel_time = false in config.ini the error is 0.086' instead of 0.218'. I think this would be good enough.

But according to JPL Manual it should be true.
Positions or values (like RA and DEC) which take into account factors that appear to change the target position with respect to the background coordinate system: light-time, the deflection of light due to large or nearby masses, and stellar aberration.

image

@gzotti
Copy link
Copy Markdown
Member

gzotti commented May 11, 2026

Appendix F in the User Guide shows typical errors in past and present times. I cannot say where the 0.35' come from, it's larger than what our list . To exclude any topo efect, switch off topographic positions in Stellarium and Horizon. The Neptune graph looks like it has a monthly wobble on top of an annual wobble. Both are weird, but is the JPL position geocentric or (Earth-Moon-) barycentric? What about nutation? aberration? (isn't that annually 22''~0.35'?!)

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

Labels

data Missing/bad/outdated data, but no code error

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

3 participants