Dynamics module

[nyx-space]

Dynamics module

[ChristopherRabotin]

I kinda need the two body dynamics right now, so I'll be creating a branch called issue-5a which only tackles that. It'll likely require some changes in the propagators, but I'll try to keep these changes as minimal as possible, while also making the use of a Dynamics trait as simple as possible.

[ChristopherRabotin]

Progress report

Proof of concept works. However, there is a need to do a closure to provide the eom to derive of the Propagator. That's kinda ugly, and really should be avoided. So I need to find a nice way to rewrite the following to avoid boilerplate (and arguably confusing) code:

let (t, state) = prop.derive(dyn.time(), dyn.state(), |t_: f64, state_: &Vector6<f64>| {
            dyn.eom(t_, state_)
        });
        dyn.set_state(t, &state);

I'll probably want something like prop.derive_dynamics(dyn);. I'll have to make sure to avoid circular imports (not sure that's a thing in Rust).

Potential issues to keep in mind

• The eom function stores the equations of motion. This might make the code incredibly confusing since so much stuff might happen here. That said, the current structure does allow combination of different dynamics, so that should help.
• Since we use a closure, we cannot modify anything at all in the eom (i.e. if the engineer uses fn eom(&mut self, ... instead of fn eom(&self, ... the compiler will refuse to build (because the trait has it as immutable). This means that the stuff like closed loop control might be confusing to handle at first... But in exchange for this potential source of confusion, it forces the equations of motion to be applied strictly for a given state and as such it avoid errors like applying the J2 at one half step later (which was one of my main pitfalls in smd).

TO-DO:

Even for simply subtask 1, the following need to be done:

• TwoBody needs to have an initializer via a CelestialObject (so that the mu is automatically set).
• CelestialObject needs to exist, and probably as a trait (not sure). I'll also need to create several objects of the solar system as they are defined in GMAT.
• Initial implementation of #7 / Attitude module. This is solely to demonstrate the combination of a spacecraft position and velocity and its attitude. I'll likely use quaternions since they're currently available in nalgebra.
• Extensive documentation.

[ChristopherRabotin]

Is there a way to simply combine dynamics? For example let my_dyn = TwoBody::from_state_vec::<EARTH>(init_vec) + SRP(init_time) and automatically have a struct which combines both correctly? There should be a strict check that the Self::StateSize is correct. To "extend" dynamics, e.g. add angular momentum to some body dynamics, the operator could be &: let my_dyn = TwoBody::from_state_vec::EARTH>(init_vec) & AngularMom::from_tensor_matrix(&tensor, &omega).

I think this would allow the library to be less "scary" at first sight. However, this makes it significantly harder to implement some control function which varies with time (such as including coasting orbits, thrusting with different efficiencies determined by some genetic algorithm, etc.).