Some updates on my high fidelity heliocentric propagation study. Good news, for my sample asteroid I’m able to match the Horizons reference ephemeris to within the uncertainty Horizons has on it. Over 100 years that’s about 200 km position error and less than 1e-5 km/s velocity error. I have two plots attached to show that. To get that I have to include the top 16 asteroids (beyond that it doesn’t make much difference) and general relativity. I also had to implement a sun-centered version of the ICRF frame.
At a minimum I would like to get the sun-centered ICRF frame in the main source code.
I have a JPL Ecliptic frame coded as well but I need to experiment with that more to confirm it’s working as well as the sun-centered ICRF. I couldn’t get barycentric working well at all. That’s for another discussion though.
There is also the question of the reference asteroid ephemeris. For now I have it coded up to read it out of a SQLite database. Do we think our SPICE bsp file readers would be able to read generic SPICE files not just the DE files? If so it may be better to ingest it that way rather than bringing in SQLite dependencies and their exceptions. Assuming the SPICE idea works having it in the main source code is a lot easier of a solution.
There are some light documentation updates needed too around Earth-centric terminology used for certain things (like the Relativity force model) and some clarifying of documentation on changing out DE files.
An interesting thing which may be of note is the time of propagation. When I was running my unit tests the 100 year propagation were taking excessively long, on the order of ten minutes. I was expecting I’d have to run JProfiler to see where we could get some optimization. However when I ran a test case where I was marching through the number of asteroid perturber count I found a pleasant surprise. It seems that it was the initial pass building up the polynomials where we really take the hit. For a “warmed up” case where we have the fully loaded all the planetary ephemeris and started loading asteroid ephemeris the run time drops down to 20 seconds, then starts increasing from there. I ran a subsequent test where I “warmed up” the ephemeris caches and confirmed this. I don’t know if there is a more efficient way to do this than to just march through time but I thought it was worth highlighting. it’s a problem for one off computations but less so for persistent servers.
We’ve had some discussions about that. Adding support for generic SPICE files could be a good new functionality for Orekit. I don’t know where those discussions stand. But I think that nothing has been done to add support for generic SPICE files. I hope someone will confirm what I’m saying.
That’s a strange behavior. Is there an optimization problem with your data loader? But I’d be curious to use an optimization engine to see why exactly it taker about 10 minutes at the beginning.
Thank you Hank for your work and your updates. That’s really interesting!
I confirm that (to my knowledge) nothing has been done on SPICE kernels reading with Orekit.
I do also think this would be a very good addition.
The feature was asked by a user during the first Orekit day back in November 2017. But no one asked for this again since then and no one had time or need to do it for a project.
Your project may be a good opportunity to develop this feature Hank.
This is with the JPL Planetary loaders built into Orekit for all the major solar system bodies. It’s not that strange really since I think it only loads the segments that it needs for a given computation. Once it’s loaded it’s permanently cached. However before that it goes through, figures out what to load, loads it, builds up the equations etc. What I don’t know is if it is possible to bulk load the caches with the entire DE file. That’s what I’m doing for the asteroids when I first encounter one.
On the SPICE kernels in Orekit we would have two options. The first option would be to use the standard JPL libraries. The second option would be to write our own libraries with extensive unit tests for just the parsers aspect of reading (maybe also writing) SPICE files. The big advantage of using the JPL libraries are that they are heavily validated and hypothetically maintained by JPL along with the other language implementations. The bad news is that they are not Java Native. They use JNI to call down into the C-libraries. The other bad news is that as far as I can tell they don’t have them pushed up to a Maven repo anywhere. That means we’d have to handle their library somehow and train our build scripts to be platform aware (both CPU and OS). It could be a great service to write JVM native versions of this library, even if just for a subset of SPICE capabilities, but it would not be a small development operation.
Yes I suspected this would require a large development.
Do you know if they have publicly available test cases somewhere ? This would at least reduce the amount of time required.
They do ship with a test suite. I’m not sure how directly usable it would be since it is very specifically hardwired to the JNI calls in their native libraries but it would be able to be used to create a reference unit test for another library.
I have recently become interested in loading SPK binary kernels in Orekit and found this thread! Would there still be interest in this feature? If so I’d be happy to contribute towards implementing readers and evaluators for the different types of SPK kernels. I think it could be interesting, since there is a lot of information available distributed as SPK kernels. I have available a test suite for loading and evaluating all kernel types, with results verified against those produced by CSPICE, which we could easily port to Java.
