Using SPICE files for ephemeris

[ChristopherRabotin]

Feature request

Instead of relying on downloading data from HORIZONS, I recommend using ANISE, which is a pure-rust SPICE interface to read ephemeris data from SPICE files. I'd be thrilled to help with that integration, especially given that I have yet to write thorough documentation for ANISE.

For reference, HORIZON uses the SPICE files under the hood, so switching to ANISE would work the same with, but one would only need to load the data from a local copy or from the public S3 bucket I have setup.

[jan-tennert]

Hey, your library looks promising! Currently the data gets stored in a json file which can be edited with the external UI I made. Feel free create a PR integrating your library if you want!

[jan-tennert]

Hey, @ChristopherRabotin. I'm currently working on an editor and integrating ANISE. Here is what I got so far with the ANISE integration:

Screencast_20241003_133726.webm

I have some questions as I'm not that familiar with SPICE files:

• What should I store for the bodies besides the NAIF Id. Is the orientation and target important? (Maybe you could set the target scenario wide, scenarios are what you create in the editor)
• For the solar system scenario you have planets and their biggest satellites/moons. SPK files like de440 only contain the planets, should I then add separate SPK files for each planet (like sat545 for saturn moons)
• What does the error Error: SPK { action: "translation to parent", source: UnsupportedDatatype { dtype: Type1ModifiedDifferenceArray, kind: "SPK computations" } } mean? Context: I'm trying to create a scenario for illustrating voyager-1 flybys using data from https://naif.jpl.nasa.gov/pub/naif/VOYAGER/kernels/spk/, but using the target id -31 gives me this error.
• I saw something about rotations on the ANISE documentation. Is that something that the Simulation could use?

Here is the majority of the integration: https://github.com/jan-tennert/SolarSim/blob/main/src/simulation/components/anise.rs

[ChristopherRabotin]

Hi Jan,

This demo looks GREAT! I'm really looking forward to seeing more of it.

Now, let me answer your questions:

• You may wish to also store the tri-axial ellipsoid that defines the shape of the body. When you load the pck11.pca file in ANISE, it'll load in the shapes and rotation equations that NASA uses (and most missions outside of Earth orbits). This is stored in ANISE as PlanetaryData. To retrieve it, the simplest is to call frame_from_uid where the input could be IAU_MOON_FRAME for the body fixed Moon data (the body fixed frame is used for latitude, longitude, and altitude computations because it rotates over time with the object, whereas an inertial frame does not rotate). That function will return a copy of the frame with the planetary data set, so you can just do something like the following:

let iau_moon_frame = almanac.frame_from_uid(IAU_MOON_FRAME).unwrap();
println!("{}", iau_moon_frame.shape.unwrap());

You can find an example of how this is used here: https://docs.rs/anise/0.4.2/src/anise/astro/orbit_geodetic.rs.html#199-228 . Note that I'm referencing the docs from two releases ago because of nyx-space/anise#302.

• Correct: the DE files (developmental ephemerides) only contain the Earth, Moon, and then the barycenters of all the other planets. For the moons of other planets, you'll need to load these specific files, but note that they may be large. I think that the Jupiter file is over 1 GB.

• This error is because ANISE does not yet support the Type 1 interpolation method. Most recent SPICE files use Chebyshev, Hermite, or Lagrange interpolations, so I've focused on those. I just created an issue to tackle that type 1 format: Support SPK Type 1 - Modified Difference Arrays nyx-space/anise#330 .

• Yes, you'll want to use the precise rotation of each celestial object if you start mapping the illumination onto a texture of that object. These rotations are initially defined by the International Astronomy Union and published by NASA under the pck00011.tpc file, repackaged as an ANISE binary input file as pck11.pca.

Let me know if I can support your effort.

[jan-tennert]

Thank you!
So I'm now retrieving & storing the shape (working on applying them to the model), but confused about rotations. So there is Almanac#rotation_to_parent returning a rotation matrix but also from CartesianState 6 from these methods. I'm currently using the former, but that obviously doesn't look right looking at the axial tilt of the mars. Maybe also need to consider the initial orientation/rotation of the model

video.mp4

[ChristopherRabotin]

Hi Jan,

I agree, that looks odd. I think that the parent of the IAU Mars frame is the J2000 frame, and that frame is roughly aligned with the rotation axis of the Earth on 01 Jan 2000. The solar system axis is the J2000 Ecliptic frame. You can use either the rotate function (previously called rotate_from_to, cf https://docs.rs/anise/0.4.2/anise/almanac/struct.Almanac.html#method.rotate_from_to) or you can composé thé rotation matrix with the built-in angle: https://docs.rs/anise/0.4.2/anise/constants/orientations/constant.J2000_TO_ECLIPJ2000_ANGLE_RAD.html.

Let me know if that looks better, I think it will.

[jan-tennert]

Yea thanks, I think that works:

2024-10-07.20-05-07.mp4

Btw, is there a way to unload loaded SPK files? I couldn't find such method

[ChristopherRabotin]

Holy cow this looks amazing! You even have terrain models on the Earth from what I can tell from the shadows! NASA also published very details terrain models of the Moon (and a few other objects) if you're interested (I think the LDEM model is the best DTM for the Moon, but I'm not sure).

I don't think that it's currently possible to unload an SPK file. What I usually do is simply let the SPK fall out of scope and Rust will clear the memory automatically. I think you can also access the almanac as mutable and replace the SPK you want to unload with None directly in the spk_data array: https://github.com/nyx-space/anise/blob/master/anise/src/almanac/mod.rs#L67 .

[jan-tennert]

Thank you very much for your help! I'm currently used the 3D models published by NASA, but I'll investigate the LDEM models!
I think we can close this issue now! If you have any other suggestions or ideas, feel free to tell me!