Urgent: Support J2 in celestial dynamics

[ChristopherRabotin]

I was initially hoping to code up the full gravity field models instead of coding J2 separately, but I need this feature although I hadn't planned that.

• [x] Load EGM and SHADR files
• [x] Load .cof GMAT files for validation of the computation
• [x] ~CANCELED: Implement the spherical harmonics computation using vectors instead of matrices (should speed up computation, but also Vectors allow for runtime allocation, which isn't easily the case of matrices in rust (compile prefers knowing how memory needs to be allocated at compile time).~
• [ ] ~Validate: J2 validation will be handled once the body fixed frame can be computed~
• [x] Think about how to parallelize this calculation: this can be quite heavy with high fidelity models. Keep in mind however that, unless using tokio, Rust processes are heavy (they aren't co-routines like in Go).

[ChristopherRabotin]

I'll be supporting spherical harmonics through this issue as well.

Relevant GMAT code:

• CalculateFullField
• CalculatePointField
• CalculateField(1)

As discussed on the Open Planetary Slack, I'll be using EMG2008 which is a 2190x2159 gravity model for Earth based on the GRACE mission. A very similar data format is available for Mercury, Venus, Mars and the Moon, cf. PDS Geoscience.

I hope to embed these models into nyx, but I'm not quite sure how to do that just yet. If I am able to embed these, they will be embedded in gunzip format, and deflated on load using the flate2 crate. For performance reasons, I'll be adding some debug! statements about the loading time and the computation time. This will help me determine whether some of this computation should be done in different threads, and if so, how I should handle that (e.g. one new thread at each iteration, or one thread which handles only the gravity computations).

Finally, I'll attempt to convert the JGM3.cof coefficient file released with GMAT 2016a to the .tbl format of the aforementioned sources. This would allow me to validate the implementation of the gravity models.

[ChristopherRabotin]

Running significantly late on this. I spent too much time trying to load these simple text files using nom. I've switched to string parsing using std::String, and I can now load the files correctly. Moreover, I've spent quite some time rewriting the GMAT algorithm so that all the calculations hold in a set of three vectors of f64 (GMAT uses matrices all over the place, and I haven't found a good justification for it). Hopefully I'll get this done in the next 24 hours, and can move on to SPK loading for version 0.0.4.

[ChristopherRabotin]

Ugh, something is broken in the algo implementation since I have a zero vector of contribution of the spherical harmonics...

[ChristopherRabotin]

For the parallel computation, I think the best strategy is to enable a thread pool with a dynamics model. From there, each dynamic model would be computed on its own thread. That thread will last throughout the propagation, preventing any overhead for creating and killing the thread.

[ChristopherRabotin]

Current status on the harmonics: the code is the same. However, I have a serious problem with the implementation of the step size control which I've been hunting for 2 full days now (cf. #3 ). I'm really not sure what the issue could be currently.