Better Ephemerides, Rotation Models, and a Solution to X64 Builds

[n72.75]

The major roadblock to OpenOrbiter 64bit stability is a lack of source code for some of the celestial bodies (mostly moons of Uranus and Mars).

In past Orbiter releases, these were always packaged as just a DLL and I'm not sure Dr. Martin S. ever had the source, at least it was never added to GitHub; to the best of my knowledge these were created prior to Orbiter 2006 by a forum (M6) user.

This was noted here:

Celbody modules with no source code

Hi, I'm having NaN (as in Not A Number) issues related to celbodies with binary only modules (Deimos, Phobos...). I tried to patch their config files but it turned out I made a mess of it... Anyway, is there a reason for not having the source code for these? (licensing issues, code lost, or...

www.orbiter-forum.com

And we have a Github issue for the effect that it causes in 64bit builds: If you want to see what injecting NaN's into the propagator looks like...

Physics Instability Caused by 32 bit DLLs · Issue #243 · orbitersim/orbiter

This issue is most noticeable when taking off from Mars in some of the default Delta Glider or Shuttle A scenarios. Reference: Piraxus/OrbiterSkyboltClient#8 I have noted similar issues randomly ta...

github.com

If we want stable x64 builds (and we will need them at some point, if we want development to continue) we have several options:

1. Delete the offending moons from the default Sol system.
2. Hope the original author of these modules returns at some point and blesses us with the source code.
3. Replace the modules entirely.

Of these three options, #3 is by far the best, and while this may at first seem like a tremendous undertaking, a huge amount of work has already gone into implementing it.

While testing my tesseral gravity project (which I also need to revisit) I used this SPICE/DE440 which brings with it a whole host of improvements to ephemerides accuracy and rotational position.

The only real downside I can see is that SPICE kernels can get rather large (1960 to 2050 is 600MB), but on the other hand most of us have 55+ GB of planetary textures laying around, so that's not bad. How we handle this on Github is another story.


I am making this thread because of a discussion that @Ajaja and @Boxx . This can serve as a discussion jumping-off-point, and we can also discuss on Discord. At the moment, I am looking for some feedback from the community.

 

[GLS]

SPICE kernels can get rather large (1960 to 2050 is 600MB), but on the other hand most of us have 55+ GB of planetary textures laying around, so that's not bad.

Still, 600MB for a (small) moon seems to be a bit excessive to me. The Saturn system alone would be over 15GB.

How we handle this on Github is another story.

I don't think that can be put in there for free...
Maybe a similar solution to the textures and elevation data should be used (whatever it is).

 

[n72.75]

Still, 600MB for a (small) moon seems to be a bit excessive to me. The Saturn system alone would be over 15GB.

Sorry, I wasn't clear. That's 600MB for the whole solar system from 1960 to 2050.

These bodies:

Summary for: orbiter.bsp
 
Bodies: MERCURY BARYCENTER (1)  IO (501)                ARIEL (701)
        VENUS BARYCENTER (2)    EUROPA (502)            UMBRIEL (702)
        EARTH BARYCENTER (3)    GANYMEDE (503)          TITANIA (703)
        MARS BARYCENTER (4)     CALLISTO (504)          OBERON (704)
        JUPITER BARYCENTER (5)  AMALTHEA (505)          MIRANDA (705)
        SATURN BARYCENTER (6)   HIMALIA (506)           URANUS (799)
        URANUS BARYCENTER (7)   JUPITER (599)           TRITON (801)
        NEPTUNE BARYCENTER (8)  MIMAS (601)             NEREID (802)
        PLUTO BARYCENTER (9)    ENCELADUS (602)         PROTEUS (808)
        SUN (10)                TETHYS (603)            NEPTUNE (899)
        MERCURY (199)           DIONE (604)             CHARON (901)
        VENUS (299)             RHEA (605)              NIX (902)
        MOON (301)              TITAN (606)             HYDRA (903)
        EARTH (399)             HYPERION (607)          PLUTO (999)
        PHOBOS (401)            IAPETUS (608)           VESTA (2000004)*
        DEIMOS (402)            PHOEBE (609)
        MARS (499)              SATURN (699)
        Start of Interval (ET)              End of Interval (ET)
        -----------------------------       -----------------------------
        1960 JAN 01 00:00:00.000            2050 JAN 01 00:00:00.000

 

[Ajaja]

Orbiter now has an API for implementing any ephemerides. It's just a matter of packaging and perhaps revising some existing plugins, such as the SPICE module.
However, an API for utilizing better rotation models still needs to be implemented in the OpenOrbiter core, preferably as an extension of the current CELBODY API.

 

[Boxx]

Sorry, I wasn't clear. That's 600MB for the whole solar system from 1960 to 2050.

These bodies:

Summary for: orbiter.bsp

Bodies: ....

I understand that you extracted these bodies from available other kernels and made a new one called "orbiter.bsp", didn't you? It seems to cover all these bodies, indeed, but when were ithe source kernels published last? (as we experienced some shifts wrt Jupiter's moons, for instance). Probably the aareadme.txt in the SPICE subfolders could tell it. Otherwise the "comment" section of the .bsp kernels.

And I agree with @GLS to store/seed outside the git would be preferable, like textures... (git would probably not allow such large file, would it?)

 

[Ajaja]

I understand that you extracted these bodies from available other kernels and made a new one called "orbiter.bsp", didn't you? It seems to cover all these bodies, indeed, but when were ithe source kernels published last? (as we experienced some shifts wrt Jupiter's moons, for instance). Probably the aareadme.txt in the SPICE subfolders could tell it. Otherwise the "comment" section of the .bsp kernels.

Look here:

Discussion - Improved (Tesseral) Gravity Model

I updated my branch with the latest commits, and thought it would be a good opportunity to a record a (relatively) short video of this in action.

orbiter-forum.com

Kernels\orbiter.mrg is the config file for spkmerge tool (from SPICE toolkit) that creates *.bsp form other *.bsp.
Original kernels are here:

Index of /pub/naif/generic_kernels/spk

 

[GLS]

(git would probably not allow such large file, would it?)

I'm not sure git in general has any limits, but github has (I think) a 100MB commit limit, and a free repo also has a size limit for the whole thing... don't remember what it is but, I'm sure that playing with large binary files, the limit would be reached quickly.

 

[n72.75]

I'm not sure git in general has any limits, but github has (I think) a 100MB commit limit, and a free repo also has a size limit for the whole thing... don't remember what it is but, I'm sure that playing with large binary files, the limit would be reached quickly.

Yeah, I agree that these should be a separate download. Maybe include a minimal size kernel, for a few months around the date rage limited to a few megs. It should also be made obvious to the user that they need-to/should-probably download this. Maybe this module could display a splash-screen warning or some info about the covered date range.

 

[misha.physics]

Sorry, I would like to clarify something. Do I understand correctly that all celestial ephemerides for the x64 Orbiter build were not taken from the original Orbiter 2016, and some of them affect craft jumping/instability near the planet's surface? Maybe that is a reason to replace ephemerides for all celestial bodies, because we can't be sure that the other ones (for other bodies) are good at all. Or not?

And is there any difference between the x32 and x64 Orbiter builds on github for "end-users"? Performance, graphics, gaming features, etc?

 

[n72.75]

Sorry, I would like to clarify something. Do I understand correctly that all celestial ephemerides for the x64 Orbiter build were not taken from the original Orbiter 2016, and some of them affect craft jumping/instability near the planet's surface?

That's partially correct. All the bodies that we have the source code for (the ones Martin wrote) currently build without issue in both 32 and 64 bit Orbiter. Some of them: Phobos, Demos, Moons of Uranus and Neptune. We do not have the source code for. We only have the 32 but DLL. When 64 bit Orbiter tries to open 32 but DLL, things break.

Maybe that is a reason to replace ephemerides for all celestial bodies, because we can't be sure that the other ones (for other bodies) are good at all. Or not?

If we want Mars, Uranus, and Neptune to have their moons in the 64 bit build, we need to create new models for them. I am proposing this solution because:

Most of the work is already done.
It vastly improves the simulation accuracy.
It is more scalable and easy to update.

And is there any difference between the x32 and x64 Orbiter builds on github for "end-users"? Performance, graphics, gaming features, etc?

The main reason to move to 64 bit builds is that eventually Windows/Desktop Linux etc will probably move to 64 bit only. Mostly about keeping up with the times and making sure Orbiter doesn't become a relic of the Windows XP era.

 

[misha.physics]

All the bodies that we have the source code for (the ones Martin wrote) currently build without issue in both 32 and 64 bit Orbiter. Some of them: Phobos, Demos, Moons of Uranus and Neptune. We do not have the source code for.

Thanks, I thought we didn't know which bodies cause problems. And what about Mars itself? Or the instability of the crafts near Mars surface is caused by its moons? It's interesting and not clear how ephemerides can cause such effects. It's probably because the movement of these problem celestial bodies is intermittent, and this is especially noticeable during the relative motion of the craft near the surface, isn't it?

 

[n72.75]

Thanks, I thought we didn't know which bodies cause problems. And what about Mars itself? Or the instability of the crafts near Mars surface is caused by its moons? It's interesting and not clear how ephemerides can cause such effects. It's probably because the movement of these problem celestial bodies is intermittent, and this is especially noticeable during the relative motion of the craft near the surface, isn't it?

It's not caused by Mars. Definitely the moons.

It's also not caused by the ephemerides, specifically.

The cause is that when 64 bit Orbiter points it's pointers into a 32 but Phobos/Diemos DLL to ask for gravity contributions to the forces on your spacecraft, it gets absolute garbage back instead of real numbers.

 

[Ajaja]

A quick solution for addressing the issue with the moons in x64 builds would be to switch back to using elements:

elements.ipynb

elements.ipynb. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

[n72.75]

A quick solution for addressing the issue with the moons in x64 builds would be to switch back to using elements:

elements.ipynb

elements.ipynb. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

That is very likely the best short-term solution and avoids a lot of other complications. For the average user the positions of these bodies doesn't need to be accurate to tens of meters over thousands of years too.

 

[N_Molson]

I'm not too concerned by the size of the files. Sure, it is always best to have smaller files, as it makes things easier from a memory access standpoint. On the other hand, if we want to simulate accurately the whole Solar System, which I think is pretty much the point, it actually is a lot of data.

 

[Linguofreak]

That's partially correct. All the bodies that we have the source code for (the ones Martin wrote) currently build without issue in both 32 and 64 bit Orbiter. Some of them: Phobos, Demos, Moons of Uranus and Neptune. We do not have the source code for. We only have the 32 but DLL. When 64 bit Orbiter tries to open 32 but DLL, things break.

This is something I've never understood. Why are Orbiter ephemerides DLLs in the first place? This seems like something that should be data, not code.

 

[Ajaja]

I've updated the SPICE celestial body module for Orbiter and published it on GitHub:

SPICE module

Thanks. There is currently no kernels folder in my Orbiter folder. Am I supposed to create it? Strange. There is must be empty "Kernels" folder in zip above. Maybe it was not unpacked because it's empty? You can create folder, or just change settings in Phoebe.cfg from "Kernel =...

www.orbiter-forum.com

GitHub - Ajaja/spice_orbiter: SPICE celestial body module for Orbiter

SPICE celestial body module for Orbiter. Contribute to Ajaja/spice_orbiter development by creating an account on GitHub.

github.com

 

[n72.75]

I will look into what needs to be done to add this into an OO branch in a few days. I have a few other open projects that I need to finish first.

 

[Ajaja]

Additionally, this module has the ability to function beyond the time period covered by SPICE kernels. It calculates osculating elements at the boundaries of the period and utilizes them outside the designated timeframe. This feature can help address the issue of distributing a large *.bsp file with the module. Instead, a smaller file can be provided, while the large kernel files covering extensive time periods can be made available as downloadable additional content, similar to textures.

 

[kuddel]

[...]Instead, a smaller file can be provided, while the large kernel files covering extensive time periods can be made available as downloadable additional content, similar to textures.

That sounds fantastic!
As I do not have any idea of the SPICE-library and it's inner workings, is it possible to give a rough ratio of the size differences?
Something like "basic" 10 MB vs. "max-fidelity" 300 MB ?!
It does not have to be accurate, I just like to know if there's orders of magnitude involved.