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]

You can select deltaT model in the time settings.

Yes, I am aware of this. I wanted to automate it via the API, but I couldn't find a way.

[gzotti]

core.getDeltaTAlgorithm(), core.setDeltaTAlgorithm("WithoutCorrection")

[schenlap]

I think the codeFactor errors are fase positives. The only thing I could change would be the extra white spaces in

    params = {
        "format":      "json",
        "MAKE_EPHEM":  "'YES'",
        "COMMAND":     f"'{cmd}'",
        "EPHEM_TYPE":  "'OBSERVER'",
        "CENTER":      "'coord@399'",      # geodetic surface observer on Earth
        "COORD_TYPE":  "'GEODETIC'",
        "SITE_COORD":  f"'{lon:.6f},{lat:.6f},{alt_km:.4f}'",
        "START_TIME":  f"'{jd_to_date_str(jd_start)}'",
        "STOP_TIME":   f"'{jd_to_date_str(jd_stop)}'",
        "STEP_SIZE":   f"'{step_days} d'",
        "QUANTITIES":  "'1'",              # RA/Dec (ICRF)
        "ANG_FORMAT":  "'DEG'",
        "CSV_FORMAT":  "'YES'",
        "CAL_FORMAT":  "'BOTH'",
        "TIME_DIGITS": "'MINUTES'",
        "EXTRA_PREC":  "'YES'",
    }

but here the whitespaces make it better readable. Please add a note if i should change this.

@worachate001

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

i am only waiting for feedback here, than my PR wold be ready for review.

[worachate001]

I just found an issue in new orbital elements. Look at Elara (Jupiter's moon), orbit_Ascendingnode should be updated to the new epoch, but it's not.

[schenlap]

I debugged it. It was an issue with lower-case writing of node. Fix will follow soon

[schenlap]

Errors before this PR (with DE440 installed and enabled):

Only the red ones are changed (with error greater than 2')

This is the result after this PR:

I can add the complete pdf report before and after this PR if needed.

[schenlap]

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

This should probably be handled in a follow-up by someone more familiar with this area.

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

This is an automatically generated QA checklist based on modified files.

[gzotti]

An error of one degree for the Moon is definitely wrong data. You can also see there is no before/after change. Are you sure to have topographic correction switched off? Also Mercury, 1/4 arcminute sounds like its topographic parallax. For the rest, whatever exceeds single-digit arcminutes I guess this indicates a principal issue (misunderstanding) with the geometrical orbit model, even if (probably) mean longitude is updated and therefore the respective moon is at least "on the right side of the planet" for now. But as said, the orbital model is legacy code, unfortunately not documented by the original creator. Somebody should look into the topic with the question "given orbital elements from JPL, how to compute planet moon positions". Thinking it over and starting from scratch.

EDIT: We can of course accept the new data that makes the error apparently less severe, even if the orbital model remains wrong. But please try to remove the systematic error (topocentric parallax) in your investigation - just observe from the geocenter.

[schenlap]

An error of one degree for the Moon is definitely wrong data. You can also see there is no before/after change.

I did only change objects with orbit data, not special function like coord_func=lunar_special. Our moon ist not changed.

My Settings changed from default:

Is there anything else I should change?
I am still not able to get as good results as #4908 (comment) but don't know why.

[gzotti]

Did you also set geocentric observer in JPL Horizons?

[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!