Define interface for AbstactKiteModel

[ufechner7]

Our four models should support a well defined interface for:

• creating an instance of the model
• initialization
• next_step! function including input parameters
• update_sys_state! function
• reporting errors/ exeptions

This would make it easier to write examples that run with any of the models.

[ufechner7]

1. model = KiteModel(set) where set::Settings and KiteModel one of KPS3, KPS4, KPS5 and RamAirKite
2. integrator = init_sim!(model; kwparams...) One of the keyword parameters should be prn::Bool which can be used to enable or disable @info messages
3. next_step!(model, integrator; kwparams...) The following keyword parameters should be supported: set_speed, set_torque, v_wind_gnd, upwind_dir, dt)
4. update_sys_state!(ss::SysState, s::AKM, integrator; kwparams...)
5. in case of an error an @error message shall be printed AND an exception raised

Alternatively we could define that the integrator has to be stored in the struct KiteModel. Then we would not need the second parameter in 3. and the third parameter in 4.

[1-Bart-1]

Why not use CommonSolve.jl? I think it makes sense to have the integrator stored in the KiteModel struct.
I would use the kwarg set_values which is interpreted as a speed or a torque depending on which WinchModel is used.

[ufechner7]

I would use the kwarg set_values which is interpreted as a speed or a torque depending on which WinchModel is used.

This is not possible, because using both is allowed with the torque controlled winch model. If you use the set_speed, it uses an internal PID to translate that into a torque.

[ufechner7]

Why not use CommonSolve.jl? I think it makes sense to have the integrator stored in the KiteModel struct.

One reason is, that it is not sufficient. We need update_sys_state! and the type SysState for logging and plotting. And I don't think we can define a solve function because we have a hybrid system and cannot/ don't want to use callbacks. We actually have a dual rate hybrid system, nothing the CommonSolve interface is designed for.

[ufechner7]

If we store the integrator in the KiteModel struct, it would look like this:

1. model = KiteModel(set) where set::Settings and KiteModel one of KPS3, KPS4, KPS5 and RamAirKite
   The model struct must have the fields set::Settings and integrator and am::AtmosphericModel and iter::Int64
2. init!(model; kwparams...) One of the keyword parameters should be prn::Bool which can be used to enable or disable @info messages. The integrator of the model will be initialized.
3. next_step!(model; kwparams...) The following keyword parameters should be supported: depower, steering, set_speed, set_torque, v_wind_gnd, upwind_dir, dt). Unused parameters have the default value nothing. set_speed and set_torque are vectors with one or three elements. The integrator of the model will be updated.
4. update_sys_state!(ss::SysState, model; kwparams...). Depending on the model, the data stored in the model struct directly, or the data from the integrator field of the model will be translated into a SysState struct.
5. in case of an error an @error message shall be printed AND an exception raised
   Not so clear if we should call the model parameter "model" or "s". Or perhaps "m" or "mo"?

[1-Bart-1]

If you use the set_speed, it uses an internal PID to translate that into a torque.

Didn't know that, very useful!

[1-Bart-1]

Not so clear if we should call the model parameter "model" or "s".

I don't know where s comes from. It is convenient, because it is shorter to write, but I think using 1 letter names is bad practice as it makes the code hard to understand... So I would prefer model.

[1-Bart-1]

Or perhaps "m" or "mo"?

We can use model in public functions, and m for convenience in private functions.

[1-Bart-1]

it would look like this

I think this looks good! But I think that calling the functions init! and step! is better and more julia-like, because they take the model as the first argument. You "initialize" the "model".

[ufechner7]

I updated my last proposal. Better now?

[1-Bart-1]

Yes, looks good!

[ufechner7]

I renamed step! to next_step! to avoid clashes with the common solve interface.