Timestep propagator

[AlexS12]

Rewriting of work in #48 with a cleaner history

Roadmap

• Implement a basic type to store results
  • Open an issue to improve ResultsStore with desirable features (plotiing, show, variables setup...)
• Basic implementation of a propagator based on OrdinaryDiffEq (Setup equations of motion with DifferentialEquations.jl? #46)
  • Trimmed aircraft remains stable after propagation
• close Input generator #64
• Rebase master
• Receive inputs as an argument of the propagation
• Documentation of propagate and propagate_time_step functions
• Documentation of ResultsStore
• Tests generalization

  • Stevens coordinated turn for F16 (WIP)

    • TESTS currently not passing. It probably has to do with coarse tolerances in https://github.com/AlexS12/FlightMechanics.jl/blob/master/test/aircrafts/f16.jl#L466
    • Check the integration with the expected trim outputs to discard a problem in the propagation loop
    • solve Set acceleration and angular acceleration in trimmer State #69 to check against:
      
    • implement a test for X10, X11 (North, East):
      

  • Test all the dynamic systems

  • Test C310 aircraft

  • Test solve options

[zsunberg]

Hi @AlexS12 , hope it isn't rude to jump in like this! I'm an aerospace engineering professor who uses julia - so it seems likely that I will use this code one day if it turns out to be flexible and fast enough :)

First I wanted to say that I am really glad to see that you're separating the state from the dynamics. In some of my previous codes, I have put the state and dynamics in the same object and it has turned into a huge headache, so I think this was a good choice!

Second, I wanted to ask if it's possible to make ResultsStore an AbstractVector, for example, an AbstractVector{NamedTuple{...}} or maybe even just consider using Vector{NamedTuple{...}} instead of making a ResultsStore type. In this case, if you want a vector of times or states is easy enough to run

times = [r.t for r in results]
states = [r.state for r in results]

or you can still allow access to the vectors with some dataframe-like syntax, e.g., results[!,:states] returns the vector of states.

I have worked with other packages that have introduced their own non-vector types to store trajectories, and they have always been a huge pain to work with.

Also, why is there a vector of Aircraft objects in a ResultsStore? Can the aircraft change over time?

Happy to talk more about this if you are looking for input!

[AlexS12]

Hi @AlexS12 , hope it isn't rude to jump in like this! I'm an aerospace engineering professor who uses julia - so it seems likely that I will use this code one day if it turns out to be flexible and fast enough :)

Hi @zsunberg! I am glad that you found this repository and found it interesting. Thanks for your suggestions. I am sure they will help to make this package more flexible and useful 😃

First I wanted to say that I am really glad to see that you're separating the state from the dynamics. In some of my previous codes, I have put the state and dynamics in the same object and it has turned into a huge headache, so I think this was a good choice!

Yes, I had some previous experience with a similar project in python https://github.com/AeroPython/PyFME and this was one of the lessons learnt there. I still have some concerns with some of the types, but I think time, use cases and user insights will make it clearer with time.

Second, I wanted to ask if it's possible to make ResultsStore an AbstractVector, for example, an AbstractVector{NamedTuple{...}} or maybe even just consider using Vector{NamedTuple{...}} instead of making a ResultsStore type. In this case, if you want a vector of times or states is easy enough to run

times = [r.t for r in results]
states = [r.state for r in results]

or you can still allow access to the vectors with some dataframe-like syntax, e.g., results[!,:states] returns the vector of states.

I have worked with other packages that have introduced their own non-vector types to store trajectories, and they have always been a huge pain to work with.

Yes, I had some doubts with this type. I had in mind implementing the array interface interface, but it is simpler just to use an array. My idea was to implement some plotting, save, load... methods on that type. However, I think that could be accomplished on the Vector also...

In this PR I was concerned with a basic version of the propagator. I will open an issue with some ideas for the results storing soon and will take your advice into account.

Also, why is there a vector of Aircraft objects in a ResultsStore? Can the aircraft change over time?

Well, the aircraft type is still messy. It is used to dispatch on different methods depending on the aircraft type itself and also, it is composed of other types that store current value variables and are also used for dispatch in some cases:

• total forces and moments
• the flight control system: I would like to implement autopilots, stability augmentation systems... here in the future. It also stores control values and aerodynamic surfaces deflections.
• Propulsion system
• Aerodynamics

In my opinion, a good first step would be to document the aircraft and aircraft related types properly to make this clearer. I think that a clear interface is also necessary. The aircraft implementation was done a t the very beginning of the project and things have evolved a lot, as well as my Julia knowledge.

Happy to talk more about this if you are looking for input!

Really happy to continue talking and getting your insights!

[zsunberg]

(I added a couple thoughts related to the discussion above in #70 and #71)