Abstraction, type-hierarchy and modularity

[milankl]

I've started #217 which was motivated as I realised it is better to have the Parameters struct parametric with the model, i.e. Parameters{Model<:ModelSetup}. TL;DR please don't use model anymore as keyword argument, instead:

run_speedy(NF,SomeAbstractModel;kwargs...)    # or
run_speedy(NF;kwargs...)                      # or
run_speedy(SomeAbstractModel;kwargs...)

where NF<:AbstractFloat (as before) and SomeAbstractModel is an abstract type branching off the model hierarchy, following this logic:

• AbstractSupertype A
  • AbstractSubtype B
    • ConcreteType C
  • (potential) OtherAbstractSubtype B2
    • (potential) OtherConreteType C2

With most functions defined for f(::A) (the most abstract type). This is important for modularity as we want to be able to extend without redefining what doesn't need to be redefined: If we implement f(::A), then anyone can define B2,C2 later and all functions still work, only those where things differ can then be defined as f(::B2).

Longer version: These last two sentences ☝🏼 are very important, and unfortunately, we (particularly me) haven't been very consistent on this. Applied to our model hierarchy, we currently have

• (abstract) ModelSetup
  • (abstract) Barotropic
    • (concrete) BarotropicModel
  • (abstract) ShallowWater
    • (concrete) ShallowWaterModel
  • (abstract PrimitiveEquation
    • (abstract) PrimitiveDryCore
      • (concrete) PrimitiveDryCoreModel
    • (abstract) PrimitiveWetCore
      • (concrete) PrimitiveWetCoreModel

So we should in general define

• f(::ModelSetup) so that f applies to all models
• unless f doesn't make sense for a given group of models, in that case define something like f(::Barotropic) (important: Barotropic is an abstract type, not the concrete BarotropicModel as someone may want to define another model <:Barotropic in the future and then can reuse (probably most functions like) f(::Barotropic).

@maximilian-gelbrecht @white-alistair @dmey