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

[schenlap]

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

[schenlap]

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.

[gzotti]

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]

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

[schenlap]

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.

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).

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]

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.

[gzotti]

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'?!)

[worachate001]

I think the error of ~0.35' in J2000.0 coordinates may be the aberration that should not be included in that coordinate system, but technical reason makes it unable to exclude in Stellarium. Because of that, better comparison should be using:

• geocentric coordinates (Tools > uncheck 'Topocentric coordinates')
• apparent coordinates (equinox of date)
• TT timescale (not UTC) (Time > Time correction > 'Without correction')
• DE440 Ephemeris (Main > Ephemeris settings > Use DE440)

Editing some values in the python code generated reasonable and much better results.

The short and sharp peaks of error seem to occur around the time of solar conjunction, so it may be the effect of solar gravitational deflection.

[gzotti]

Yes, the 0.35' should be aberration (which you can easily switch off in Stellarium).
For the moon, I added a minuscule positional correction to adjust for "center of figure" (visible) vs. "center of gravity" (ephemeris result). This might be the "mean" effect visible in the Moon graph. The two other wobbles seek explanation, but as we are discussing in another thread, may stem from differences in precession/nutation models used by the two programs. This gets visible in the sub-arcsecond domain that we did not aim for so far, so should not concern us greatly for now. The light bending effect is interesting, but as said, we just did not go there.
Has anyone checked the actual implementation of the "generic moon orbit" code which uses all those angular arguments for Kepler orbits? Does JPL provide the right elements for the implemented model? Or does it need another frame transformation? I did not check our generic-moon code against e.g. anything in the Explanatory Supplement (2013) which gives several solutions for particular moons (and could not have checked an error by observing with my non-existing 1m backyard scope...).

[worachate001]

Yes, the 0.35' should be aberration (which you can easily switch off in Stellarium).

Indeed. You can still use J2000 coordinates, but disable the annual aberration in Stellarium. It gives near-zero errors for planets.

[schenlap]

wow, that's for the tests, that look good.

• geocentric coordinates (Tools > uncheck 'Topocentric coordinates')
• apparent coordinates (equinox of date)
• TT timescale (not UTC) (Time > Time correction > 'Without correction')
  can not be changed from API (or I did not find it). I could only add aberration disable. But that is ok for me. I will no work on the manual and test new data for every object above 2' max error.

[schenlap]

Editing some values in the python code generated reasonable and much better results.

what? Can you commit your changes in my PR?

[gzotti]

You can select deltaT model in the time settings. Am 14. Mai 2026 10:14:29 MESZ schrieb schenlap ***@***.***>:

…

schenlap left a comment (Stellarium/stellarium#4908) wow, that's for the tests, that look good. - geocentric coordinates (Tools > uncheck 'Topocentric coordinates') - apparent coordinates (equinox of date) - TT timescale (not UTC) (Time > Time correction > 'Without correction') can not be changed from API (or I did not find it). I could only add aberration disable. But that is ok for me. I will no work on the manual and test new data for every object above 2' max error. -- Reply to this email directly or view it on GitHub: #4908 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[schenlap]

I changed everything to geocentric. Now moon result is 1 arcmin.

[alex-w]

I think remarks (# source: https://arxiv.org/pdf/1803.01907.pdf) for some objects should be removed to avoid puzzling in future

[alex-w]

@schenlap please update python code according to PEP8 guide.

[schenlap]

@schenlap please update python code according to PEP8 guide.

done

[alex-w]

Thanks!

[gzotti]

I wonder about the remaining error between major planet positions. Esp. a 2-month period with Saturn error. Maybe as discussed elsewhere just spurious differences with precession models. Else this is a very nice verification contribution. And I am pretty sure the principal orbit geometry for "Keplerian" moons is flawed. But this is for another PR.

[gzotti]

I think remarks (# source: https://arxiv.org/pdf/1803.01907.pdf) for some objects should be removed to avoid puzzling in future

I think these comments refer to data entries like B-V, and should therefore stay. But probably another comment or otherwise unused data entry like "orbit_updated=fetch_ssystem_major.py on 2026-06-09" could be added. If this comment/key is found and value starts with fetch_ssystem...", update it as well.

[schenlap]

But probably another comment or otherwise unused data entry like "orbit_updated=fetch_ssystem_major.py on 2026-06-09" could be added. If this comment/key is found and value starts with fetch_ssystem...", update it as well.

this is redundant to orbit_epoch. Do you really what to add a extra date? maybe we should add a note to epoch?
orbit_Epoch=2461172.5 # fetch_ssystem_major.py on 2026-05-15

[gzotti]

"Real" comments in an ini file are in danger of "vanishing" when written by programs that ignore comments when reading the ini, which is why "unused entries" may be more durable. You are right, epoch alone may be enough, but needs decoding. I don't insist on that, just suggest. @alex-w? @10110111 ?

[alex-w]

I think remarks (# source: https://arxiv.org/pdf/1803.01907.pdf) for some objects should be removed to avoid puzzling in future

I think these comments refer to data entries like B-V, and should therefore stay. But probably another comment or otherwise unused data entry like "orbit_updated=fetch_ssystem_major.py on 2026-06-09" could be added. If this comment/key is found and value starts with fetch_ssystem...", update it as well.

OK, but comments like orbit_Epoch=2461172.5 # fetch_ssystem_major.py on 2026-05-15 is enough for me (this file is not updated by robots almost)

[gzotti]

Then I hope whichever robot will eventually update will still not mess with documentary comments.

[alex-w]

I approve it

[gzotti]

OK for me now, thanks!

[github-actions]

Hello @schenlap!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot