Orbit management module

[nyx-space]

Orbit management module

[ChristopherRabotin]

To simplify the handling of states, I might simply have Orbit be an alias for Vector6<f64> with several added functions... although the problem with this approach is that I won't be able to store any computations or add the frames. So this is actually a bad idea. The frame information (cf. comment above) needs to be available in the struct itself in order to provide reference frame transformations and prevent bad math (e.g. adding two vectors defined in different frames). Moreover, in order to do many orbital computations, I need to store the gravity parameter mu. I initially think that the best approach here is to handle that via monomorphism, e.g. Orbit::<Earth>new(). I'm also considering adding the frame as a type parameter but I'm not sure what information from a Frame object would suffice to handle everything: hence it's likely that the frame will need to be passed as a parameter instead of a type parameter. Back to the propagator information, maybe I should simply have a into_state and from_state set of functions, but that would definitely add overhead to propagator calls. In fact let (t, state) = prop.derive(cur_t, &init_state, two_body_dynamics); would become something like let (t, state) = prop.derive(cur_t, orbit.into_state(), two_body_dynamics); orbit = Orbit::from_state(). That's kinda cumbersome. Moreover, the orbital elements should be as simple to get as in GMAT: orbit.inc() or orbit.mean_brower_inc(). Finally, I need consider how I'll handle the concatenation of these different states when I have a position, a velocity, the Cr, ground station positions, etc.

[ChristopherRabotin]

After a bit more thought, I think there should be different containers for different orbital elements, may these be Keplerian elements, Equinoctal or Brower Mean. There should also be a common trait which allows for the conversion of all of them so that an Orbit (default in position velocity with a given frame, eg True of Date) can be converted to a Mean Brower Short. I also think that the intermediate conversion via a state is the simplest solution, but that may be handled directly by the Orbit structure.

[ChristopherRabotin]

Currently working on this issue, but I'm concerned about how to handle frames. What do they provide? At the very least, they should explain whether they are inertial or not. But they should also provide, I think, information about where they are centered (Earth centered, Earth-Moon barycenter, etc.) so as to allow for correct reference frame transformation. Arguably, the orbit itself only needs to know the mu (or GM) parameter (in order to properly compute the orbital period, velocity, and other stuff). That's how it is in GMAT somewhat: Earth_TOD, etc. Implementing that however, would require implementing celestial bodies as well, or at least a draft of them (as an enum ?).

[ChristopherRabotin]

I'm going to ditch the work done on this branch so far. I think that before writting frame manipulation code, I need to learn how to properly load a BSP file. From there, I'll have a better understanding as to what kind of informatiocan be in there, and how it might affect reference frame transformations. Specifically, I think the current idea of having "reference frames" which can be TOD or Julian etc. and be Keplerian, Equinoctal, etc. is a good idea, but it does not solve the problem of changing the origin of a position & velocity vector into its position into another frame. Once that's handled, I will be able to better handle the reference frame transformation.

Moreover, I hope to be able to provide a DE file in this repo, but the latest DE436 is larger than the github limit of 100 MB. So I might trim it to start at 1976 and go until 2050 or something (I believe the default version is 1900 to 2100). Moreover, note that this will require the implementation of an interpolation code, which I'll likely implement using the same algorithm as GMAT (although I might check out other algorithms which may be faster [maybe there should be a way to choose which interpolation scheme to use?]). Finally, this work will add the dependency on hifitime.

[ChristopherRabotin]

In other words, this issue depends on #4 .

[ChristopherRabotin]

Similarly to how I am implementing #5 , I'll work on this issue in different steps, as follows:

• First, provide a single struct Orbit (or OrbitalElements) which can be initialized from different ways of defining an orbit: Cartesian position and velocity,Keplerian OEs, Equinoctal and Mean Brower Short. From that object, it shall compute and provide the Mean Brower Short elements, the orbital elements in Keplerian and Equinoctal, the position and velocity. I'm not very familiar with the Brower elements, so I'll have to see how GMAT implements it, and how to convert from Brower short to other elements. I'm also not entirely sure how I'll avoid recomputation of the same information knowing that Rust does not support uninitialized values.
• As a second step, I'll add support for different coordinate frames such as True of Date. It's likely that I'll have to change the constructors as defined right above to support something which implements a CoordinateFrame trait instead of a Planet trait: to be seen.
• As a third step, I'll have to provide a function which can compute the orbital element "as seen from" another position, such as as_seen_from(another_spacecraft) or as_seen_from(Mars.position_at_time(t)).

As evident from this comment, only the first step as somewhat been thought through.

[ChristopherRabotin]

As I'm currently coding this, I think that the state should also include a time, based on hifitime of course since it supports leap seconds. This information could also be used in order to convert to a TOD frame by calling "state.tod()" which would return a new state. Maybe could that struct know whether or not it was already converted to a tod to prevent usage errors (eg initialized from a tod state and calling tod again, one would apply both rotations). If that is the selected design, then the celestial body trait needs to include the relevant rotation matrices. By default, they should be identity. I'll have to check if these rotation matrices depend on anything more than time and a fixed nutation rate depend on the planet, or more than that.

[ChristopherRabotin]

Status update:

• Cartesian (to/from)
• Keplerian (to/from)
• Mean Brouwer Short (to for now)
• Equinoctal (to for now)

[ChristopherRabotin]

Closing this as all the tasks listed here are now separated into subtasks.