Remove all hardcoded Float64 from the Advection module

[simone-silvestri]

and also correct some Float64 that slipped in the SplitExplicitFreeSurface. This is some preparatory work to allow more flexible user type and eventually fully support Metal.

Note that I have tested Metal on an additional branch that implements these changes + some (quite easy actually) support for Metal architectures https://github.com/CliMA/Oceananigans.jl/tree/ss/fix-metal (as well as some other tangential stuff I was trying which is not relevant) and this example seem to run quite nicely with WENO, so after this PR is merged, the route for Metal should be

• enable easy Float32 support
• implement a MetalGPU (alias for a possible GPU{<:Metal.MetalBackend}) architecture

[glwagner]

This is unrelated right? The difference is that “similar” doesn’t copy boundary conditions.

[simone-silvestri]

Right, this was a leftover from the Metal branch (that I stripped down for this PR). Apparently, there is a bug with deepcopy and Metal OffsetArrays:

julia> a = MtlArray(zeros(Float32, 4));

julia> a = OffsetArray(a, -1);

julia> b = deepcopy(a);

julia> fill!(b, 1);

julia> a
4-element OffsetArray(::MtlVector{Float32, Metal.PrivateStorage}, 0:3) with eltype Float32 with indices 0:3:
 1.0
 1.0
 1.0
 1.0

I wanted to raise an issue in OffsetArrays.jl but I haven't done it yet.

[simone-silvestri]

with similar, on the other hand, there is no issue:

julia> a = MtlArray(zeros(Float32, 4));

julia> a = OffsetArray(a, -1);

julia> b = similar(a);

julia> a
4-element OffsetArray(::MtlVector{Float32, Metal.PrivateStorage}, 0:3) with eltype Float32 with indices 0:3:
 0.0
 0.0
 0.0
 0.0

[simone-silvestri]

Note that this is not an issue with standard metal arrays

julia> a = MtlArray(zeros(Float32, 4));

julia> b = deepcopy(a);

julia> fill!(b, 1);

julia> a
4-element MtlVector{Float32, Metal.PrivateStorage}:
 0.0
 0.0
 0.0
 0.0

[glwagner]

weird

[glwagner]

This comment should say something like:

# List of fully-supported floating point types where applicable.
# Currently used in the Advection module for WENO advection schemes.

This comment communicates that the type is designed to be more general than just for advection, and that the comment should be changed if future development occurs.

Currently, the comment is misleading because one can interpret it to mean that a different variable should be used to specify floating point types for other modules.

[glwagner]

I think this should be a tuple rather than array. Otherwise users can change it eg

push!(Oceananigans.supported_float_types, Float16)

but of course this does nothing.

[simone-silvestri]

Sounds good, I ll do the changes