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

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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:

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

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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
6,030
Reaction score
3,075
Points
188
Website
github.com
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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:

Code:
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
 
Last edited:

Ajaja

Active member
Joined
Apr 20, 2008
Messages
226
Reaction score
93
Points
28
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

Mars Addict
Addon Developer
Donator
Joined
Nov 15, 2009
Messages
208
Reaction score
137
Points
58
Location
Paris Area
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

Active member
Joined
Apr 20, 2008
Messages
226
Reaction score
93
Points
28
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:


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

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
6,030
Reaction score
3,075
Points
188
Website
github.com
(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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Well-known member
Joined
Dec 22, 2021
Messages
468
Reaction score
592
Points
108
Location
Lviv
Preferred Pronouns
he/him
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Well-known member
Joined
Dec 22, 2021
Messages
468
Reaction score
592
Points
108
Location
Lviv
Preferred Pronouns
he/him
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Active member
Joined
Apr 20, 2008
Messages
226
Reaction score
93
Points
28
A quick solution for addressing the issue with the moons in x64 builds would be to switch back to using elements:
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
A quick solution for addressing the issue with the moons in x64 builds would be to switch back to using elements:
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

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,296
Reaction score
3,270
Points
203
Location
Toulouse
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

Well-known member
Joined
May 10, 2008
Messages
5,042
Reaction score
1,283
Points
188
Location
Dallas, TX
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

Active member
Joined
Apr 20, 2008
Messages
226
Reaction score
93
Points
28
I've updated the SPICE celestial body module for Orbiter and published it on GitHub:
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,704
Reaction score
1,378
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Active member
Joined
Apr 20, 2008
Messages
226
Reaction score
93
Points
28
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

Donator
Donator
Joined
Apr 1, 2008
Messages
2,068
Reaction score
514
Points
113
[...]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.
 
Top