Rough notes and distillation prior to 24-03-26 Tudat Developer Meeting

# Rough notes and distillation prior to 24-03-26 Tudat Developer Meeting ## Ways in which orientations are defined in Tudat (especially thrust orientations) - Issues that the current implementation has - What we would want the (refactored) functionality to do; define any boundary conditions of the implementation **J** (**issue**): Personally, the **issue** I have with the current setup is that **we encourage users to define orientations separately for thrust, rotational dynamics, aerodynamic guidance**, etc. **J** (**want**): I would be in **favour** of making the user setup the body-fixed orientation separately beforehand (in most cases). This body-fixed orientation would then serve as a basis for the thrust orientation. --- **D**: `DependentOrientationCalculator` _only available during the propagation, and not before after it?_ **D**: `DependentOrientationCalculator` requires the environment to be updated to the current time/state, and this is presently only supported inside the numerical propagation. This design could also be modified, but would take quite some work (and testing). **D**: Depending on whether you are in the propagation or not, states would have to come from _either_ the current propagated state _or_ from the environment **D**: `DependentOrientationCalculator` _only available during the propagation, and not before after it? **D**: The guidance algorithm would need to 'know' which environmental properties need to be updated, and which need not be **D**: Although I don't see any fundamental issues in changing the above, I propose that if we choose to tackle this issue, we do it separately from making the interfaces unified. One possible argument for _not_ doing this separately would be to subsume the `DependentOrientationCalculator` stuff into the `RotationalEphemeris` **D**: Is it worth our time? **D**: At present, there are (roughly) three distinct ways in which to define the body's orientation - `RotationalEphemeris`, obtained from the environment during propagation, independent of propagation, exists as a function of time `f(t)` - ODE integration of rotational dynamics. `f(x0, torque)` defined prior to simulation. - *Users can use these results as `RotationalEphemeris` after obtaining results.* An `Interpolator` is a dependent in this optional step. - `DependentOrientationCalculator` , Orientation can be defined by an algorithm which is dependent on the current translational state of the vehicle. - `f(angle-of-attack, sideslip, bank)` defining trajectory <-> body-fixed - **J**: Reading all of this made me think that, perhaps, we should simply force users to propagate rotational dynamics every time? **D/J:** Overkill in most cases. **D**: I would be in favour of keeping interfaces for actually defining what is propagated different from an _a priori_ definition of the rotation. But, making the interfaces for a rotational ephemeris (fully defined _a priori_) and a 'dependent orientation calculator' (defining _a priori_ how the orientation is calculated from the state) less distinct, or even identical > Perhaps they should stay distinct *F*: I totally agree with this point! The important distinction is between numerical propagation of orientation _and_ prescribed orientation. Whether the prescribed orientation is set through Rotational Ephemerides or through a calculator that is used at every time step should not matter too much, in my opinion. ***D***: This is, I think, an important design driver for the new interfaces ## Compiled (I intended on compiled boiled down points here, didn't really manage prior to the meeting) - users define orientations separately for thrust, rotational dynamics, aerodynamic guidance.