Celestial body/object trait and module

[ChristopherRabotin]

I think this should be its separate submodule so that each object can be in its own file: nyx::bodies::Earth; . This will be quite verbose for sure, but it'll allow for clarity.

Just like in propagators, the root mod.rs should have the trait for the Body. That should include the spherical harmonics of each body, with a possibility of setting those to zero somehow for objects were we don't have that information. It should also be possible to load these harmonics from a file, as is the case in GMAT.

Must include:

• All eight planets
• An SPK file reader with state interpolation method(s?) -- not sure how to fit that in, maybe by having one of the trait methods be the NAIF ID?

[ChristopherRabotin]

Maybe should the origin changing computations be done using Isometries, cf. http://nalgebra.org/points_and_transformations/.

[ChristopherRabotin]

Here's an idea. Maybe put all the origins with their NAIF ID or some kind of unique ID in an Enum. Then, add the possibility of creating a new origin by specifying its ID, e.g. Origins::Virtual(101). That ID, if NAIF compatible, should accept negative integer values. Then, when it comes to coordinate systems, they should be initialized with that origin, i.e. ICRF::around(Origins::Earth) or something like that but less cumbersome. Somehow, it should be possible to do something like follows:

let icrf_earth = ICRF::around(Origins::Earth);
let kep_moon = Keplerian::around(Origins::Moon);
let state_kep_moon = kep_moon.from(state, icrf_earth);
let state_kep_moon2 = icrf_earth.to(state, kep_moon);

Hot take: what I dislike here is that the state is NOT associated with a frame and coordinate system. That's gross and not representative, and therefore error prone. However, I'm not sure how to attach a frame to a state knowing that the propator takes a Vector6. Anyhow, my main priority right now is to be able to define these origins and convert between the, I can handle the ossie issues in #9.

[ChristopherRabotin]

The time span of de436 is actually from 21 Dec 1549 to 25 Jan 2650. I'm definitely going to trim that down.

[ChristopherRabotin]

I am having issues understanding how to parse the coefficients of DE436s.bsp. I also tried using the transfer format but that isn't easier. I reached out the JPL, and will continue my work on this once I hear back or get more info on how to parse this.

[ChristopherRabotin]

Links of interest:

• https://stackoverflow.com/questions/21511224/how-to-read-daf-double-precision-array-file-transfer-files
• https://github.com/brandon-rhodes/python-spk/blob/master/daflib.py