JPL Horizons Delta-T Algorithms - need to be revised

[ssimard2504]

The current implementation of Stellarium regarding the JPL Horizons algorithms computing Delta-T is limited between 3000BC and 1620. Outside this range the current algorithm simply returns deltaT = 0.0, an unacceptable situation. Since JPL Horizons should be considered a reference, it seems important to me that Stellarium JPL Horizons algorithm be revised and be capable to at least reproduce the JPL Horizons application results with some accuracy.

I recently contacted by email Jon Giorgini:

Jon Giorgini
Senior Analyst
Solar System Dynamics Group (392R)
Navigation and Mission Design Section
Jet Propulsion Laboratory
Pasadena, CA USA

He provided me with some clear guidance (though not the actual code used by JPL - as this is not authorized) on how to proceed in order to implement an algorithm in Stellarium that will reproduce results from the JPL Horizons app. Thanks to his input, I was able to complete a first draft of this implementation in a local (i.e my machine) version of Stellarium.

I was able to obtain the following performance (i.e. differences between JPL Horizons app and my version of Stellarium):

from 9999BC to 1962-01-20 : +/- 0.1 seconds differences
from 1962-01-20 to 2650-01-25 : +/- 10 microseconds differences
from 2650-01-25 to 9999AD : +/- 2 milliseconds differences

Note: JPL Horizons app clamps deltaT from Present to 9999AD to the latest EOP (Earth Orientation Parameter) prediction. So values of deltaT from Present up to 9999AD are not really meaningful.

If this is of some interest for the upcoming release of Stellarium in December 2025, please indicate how I should proceed. I have done one simple Pull Request in the past, so I assume this would be the way to go...unless you would like to verify few aspects of the implementation with me before engaging in this formal process.

[Atque]

Interesting, but are deltaT values in pre-history meaningful? How does one verify them, with no written records of e.g. solar eclipses?

Of course, being on a par with JPL is a win.

[gzotti]

Thank you for engaging in this subject. Most scientists agree ΔT before about 800BC are rough estimates at best, but of course the zero result only indicates "invalid anyhow". The best solution for us (whether for 25.4 or 26.1) would be a direct pull request that changes the ΔT value to your solution when DE* models are used. And then it would help to provide a list of positions from Horizon vs. Stellarium similar to Appendix F.9 in the User Guide. IIRC in 2021 we could not even retrieve data before 2500BC.

[github-actions]

Hello @ssimard2504!

Thank you for suggesting this enhancement.

[ssimard2504]

Very well, I will start working on a Pull Request, first cloning the latest version of Stellarium and then doing changes to this fork in order to duplicate what I have on my current copy of Stellarium.

As a preview of what is coming up, here is list of all changes that I made to my current copy of Stellarium. As you should expect there will be many changes and tweak to the code in order to implement the revised JPL Horizons Delta-T algorithm. Most notably I will incorporate the latest SOFA code and create a static library out of it. While I only need to call a single method of SOFA, I thought it would be nice to have the full library as an external add-on to Stellarium. If this is not allowed by your organisation for some 'legal' reason, please let me know right away.

[gzotti]

I don't think we would disallow SOFA. It if had been around in 2002-05, probably development would have been a lot faster. I looked briefly into it but concluded around 2021 that we were probably too far to rebase all our ephemeris models and still gain significant benefit, but if 1-3 developers integrate SOFA over the next 1-5 years, it may make some experts happier. Whatever we take over, though, should not significantly slow the program for the sake of microarcsecond results, or if we want that, allow a switch "high-accuracy with slightly lower frame rate". Most users on older PCs are happy with a few arcseconds as long as it's several frames per second.

@alex-w, @10110111 how to best integrate SOFA? In earlier times we would have a copy in external, but now I guess we need guidelines for CPM or so?

@ssimard2504 from the changelog above: The DE4*... data files are optional. If they are missing, the test should just emit a warning but continue and otherwise finish successfully. What would also be great is a chapter detailing the use around ΔT in the User Guide.

[alex-w]

License of SOFA is not compatible with GPLv2 - we can’t use it.

[10110111]

License of SOFA is not compatible with GPLv2 - we can’t use it.

How did you come to this conclusion? Is it unusable even if dynamically linked?

[10110111]

Actually yes, I see this discussion, and indeed its section 4 conflicts with the GPL generally. We could use it maybe without distributing (e.g. letting it be loaded by QLibrary on demand), but not as part of Stellarium.

[alex-w]

License of SOFA is not compatible with GPLv2 - we can’t use it.

How did you come to this conclusion? Is it unusable even if dynamically linked?

Please read about ERFA ;)