Refactor code

[ufechner7]

The code needs some refactoring.

• use SVector or MVector with a size of three for coordinates and velocities (see: https://github.com/JuliaArrays/StaticArrays.jl)
• use SMatrix or MMatrix for small, fixed size matrices
• in structs, use concrete types only
• do not use type annotations in function signatures unless required for dispatch or - in rare cases - for clarity

Progress:

• wing_geometry.jl
• filament.jl
• panel.jl
• wake.jl
• wing_aerodynamics.jl
• solver.jl

[1-Bart-1]

A few points:

• Why don't you want to use type annotations in function signatures? For forwarddiff compatibility?
• Vectors have to be Mutable a lot of the time, so not only static but also MVectors should be used.
• What is wrong with just using ::Vector and ::Matrix? edit: I found out about the speedup

[ufechner7]

First point see: https://discourse.julialang.org/t/when-should-one-type-annotate-a-function-signature/115019 and https://docs.julialang.org/en/v1/manual/functions/#Argument-type-declarations

I would use type annotations only where needed to dispatch correctly.

Only in structs types need to be defined, and it should be concrete types.

[1-Bart-1]

[quote="Satvik, post:2, topic:115019"]
For applications, I’ll generally be a lot more specific, because the odds of someone wanting to use the code in a different way are much smaller, and the users of the code are my coworkers so it’s easier to change if needed.
[/quote]

A lot of the internal functions are very specific and are more readable with the types in the function signature. Easier to debug as well. And easier for the user as well: if they try to run solve(solver::Solver, wing_aero::WingAerodynamics, gamma_distribution=nothing) with a gamma_distribution of the wrong type now, they can get some random error message somewhere downstream.

[ufechner7]

OK, there might be cases where annotations improve the clarity of a function signature. But this is not good, for example: gamma_new::Vector{Float64}

It would fail when called with an SVector or with a Vector{Float32} for no good reason.

Sometimes it is better to use @assert statements to assure that the inputs are valid.

[1-Bart-1]

OK, agreed!

[1-Bart-1]

We should close this issue in favor of more specific issues or update this issue, and we have done a lot of refactoring already.

[ufechner7]

Partially implemented. I will create a new issue for the remaining issues.