Number format-flexibility

[milankl]

As raised in #31 and #77, v0.3 is still not fully number format flexible. Main bottleneck is the Fourier Transform as FFTW.jl only supports Float32/64. For other formats we'd need to fall back to GenericFFT.jl. #136 addresses that, but there's more that needs to be done. This issue is to collect efforts to remove remaining type instabilities

julia> using SoftPosit

julia> run_speedy(Posit16)
ERROR: promotion of types Float64 and Posit16 failed to change any arguments
Stacktrace:
  [1] error(::String, ::String, ::String)
    @ Base ./error.jl:44
  [2] sametype_error(input::Tuple{Float64, Posit16})
    @ Base ./promotion.jl:383
  [3] not_sametype(x::Tuple{Float64, Posit16}, y::Tuple{Float64, Posit16})
    @ Base ./promotion.jl:377
  [4] promote
    @ ./promotion.jl:360 [inlined]
  [5] -(x::Float64, y::Posit16)
    @ Base ./promotion.jl:390
  [6] broadcasted(#unused#::Base.Broadcast.DefaultArrayStyle{1}, #unused#::typeof(-), r::StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, x::Posit16)
    @ Base.Broadcast ./broadcast.jl:1110
  [7] broadcasted
    @ ./broadcast.jl:1304 [inlined]
  [8] generalised_logistic(x::StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, coefs::Main.SpeedyWeather.GenLogisticCoefs{Posit16})
    @ Main.SpeedyWeather ~/git/SpeedyWeather.jl/src/geometry.jl:195
  [9] vertical_coordinates(P::Parameters)
    @ Main.SpeedyWeather ~/git/SpeedyWeather.jl/src/geometry.jl:184

[milankl]

While this still blows up it doesn't actually throw any errors

So it does sound that the number format flexibility is actually solved, it's "just" precision-range issues with low-precision formats that don't work.

[milankl]

#407 has an example of a T21 run with BFloat16, hence closing this rather general issue in favour for future more specific issues on low precision simulations.