Fix type inference failure in AbstractOperations

[simone-silvestri]

closes #4869

[glwagner]

I don't think this has an effect (but tell me if its not true). I think this compiles identically. We use the function since its the recommendation of YASGuide (eg type parameters should be used for dispatch, not to access type info). It's not that important, but wanted to mention.

[simone-silvestri]

It is a matter of passing arguments directly as parameteric types, which is type unstable, rather than inferring a type. The constructor cannot infer the values of an argument, but can infer the type of the arguments that are passed. Check the difference between these two constructors (which basically build the same object with just a different name)

struct InstableType{T1, T2, T3} end
struct StableType{T1, T2, T3} end

StableType(t::Tuple{T1, T2, T3}) where {T1, T2, T3} = StableType{T1, T2, T3}()
InstableType(T::Tuple) = InstableType{T[1], T[2], T[3]}()

@code_warntype StableType((1.0, 1.f0, Float16(1.0))) # This is type stable
@code_warntype InstableType((Float64, Float32, Float16)) # This is type - unstable

[simone-silvestri]

Actually, you are right. In the above case, there is no issue because LX, LY, LZ should be inferred in the function call. I will revert it. The problem arises only for constructors like this

Oceananigans.jl/src/AbstractOperations/binary_operations.jl

Lines 38 to 43 in f07428b

	function _binary_operation(Lc, op, a, b, La, Lb, grid)
	▶a = interpolation_operator(La, Lc)
	▶b = interpolation_operator(Lb, Lc)
	return BinaryOperation{Lc[1], Lc[2], Lc[3]}(op, a, b, ▶a, ▶b, grid)
	end

which should actually be

 function _binary_operation(Lc::Tuple{LX, LY, LZ}, op, a, b, La, Lb, grid) where {LX, LY, LZ}
      ▶a = interpolation_operator(La, Lc) 
      ▶b = interpolation_operator(Lb, Lc) 
  
     return BinaryOperation{LX, LY, LZ}(op, a, b, ▶a, ▶b, grid) 
 end 

[glwagner]

got it!

[simone-silvestri]

After fixing this type - instability, I have noticed I introduced another type - instability in the Field constructor in #4706, which basically just moved the already existing type instability out of the fill halo functions and inside the constructor.
This might be a bit more difficult ot solve

[glwagner]

After fixing this type - instability, I have noticed I introduced another type - instability in the Field constructor in #4706, which basically just moved the already existing type instability out of the fill halo functions and inside the constructor. This might be a bit more difficult ot solve

I missed this comment. Generally though a type inference issue in a constructor is not as important as something that gets hit every time step. If you're more specific about the issue maybe we can help

[simone-silvestri]

The type instability is in

Oceananigans.jl/src/BoundaryConditions/fill_halo_kernels.jl

Line 42 in bc42990

sides, ordered_bcs = permute_boundary_conditions(bcs)

, which previously was in the fill_halo_regions! function.
However, I'll work on merging this PR and then we can open a new one dealing with this issue

[glwagner]

The type instability is in

Oceananigans.jl/src/BoundaryConditions/fill_halo_kernels.jl

Line 42 in bc42990

sides, ordered_bcs = permute_boundary_conditions(bcs)

, which previously was in the fill_halo_regions! function.
However, I'll work on merging this PR and then we can open a new one dealing with this issue

it may not be too hard:

Oceananigans.jl/src/BoundaryConditions/boundary_condition_ordering.jl

Lines 17 to 46 in bc42990

	function permute_boundary_conditions(bcs)
	split_x_halo_filling = split_halo_filling(bcs.west, bcs.east)
	split_y_halo_filling = split_halo_filling(bcs.south, bcs.north)
	if split_x_halo_filling
	if split_y_halo_filling
	sides = [West(), East(), South(), North(), BottomAndTop()]
	bcs_array = [bcs.west, bcs.east, bcs.south, bcs.north, bcs.bottom]
	else
	sides = [West(), East(), SouthAndNorth(), BottomAndTop()]
	bcs_array = [bcs.west, bcs.east, bcs.south, bcs.bottom]
	end
	else
	if split_y_halo_filling
	sides = [WestAndEast(), South(), North(), BottomAndTop()]
	bcs_array = [bcs.west, bcs.south, bcs.north, bcs.bottom]
	else
	sides = [WestAndEast(), SouthAndNorth(), BottomAndTop()]
	bcs_array = [bcs.west, bcs.south, bcs.bottom]
	end
	end
	perm = sortperm(bcs_array, lt=fill_first)
	sides = tuple(sides[perm]...)
	boundary_conditions = Tuple(extract_bc(bcs, side) for side in sides)
	return sides, boundary_conditions
	end

its been written to minimize memory allocation maybe, but at the cost of infer ability, now we can reverse this