Why does SplitExplicitAuxiliaryFields need to be extended for TripolarGrid?

[glwagner]

These kinds of deep changes into Oceananigans mean that the interface for using different grids with the split-explicit free surface is not well defined. Either we need to have a well-defined interface that only extends fields by design (not simply ad hoc), or we need to move this functionality into Oceananigans

OrthogonalSphericalShellGrids.jl/src/split_explicit_free_surface.jl

Line 14 in 5ad39ae

function SplitExplicitAuxiliaryFields(grid::TRG)

[glwagner]

I think it is actually incorrect for "split explicit free surface" functionality to appear in a package that is supposedly only about grids in the first place. Everythign in this package should be purely about grids, not physics. The fact that we have to put physics and model-specific things in this package signals that our design is wrong.

[glwagner]

Does this work for every grid?

https://github.com/CliMA/Oceananigans.jl/blob/1761a9b301718da2fbdf2afbff034dcdbe8b25b0/src/Models/HydrostaticFreeSurfaceModels/split_explicit_free_surface.jl#L221

Why? Why not?

[simone-silvestri]

The estension here in done to extend the halos in the north region where the boundaries are special. We could move this to Oceananigans. But after CliMA/Oceananigans.jl#3894 it will not be needed anymore, only the materialize_free_surface function will need to be extended

[simone-silvestri]

In CliMA/Oceananigans.jl#3894 I can also modify the materialize_free_surface to automatically extend the halos for Connected topologies such that there is no need for extending anything here

[glwagner]

In CliMA/Oceananigans.jl#3894 I can also modify the materialize_free_surface to automatically extend the halos for Connected topologies such that there is no need for extending anything here

Probably, you want to make this change regardless of whether we have a separate package for TripolarGrid or not

[glwagner]

The other disadvantage of this as a separate package is that users now have to depend on OrthogonalSphericalShellGrids, which basically adds a line of boilerplate / dependency to every user environment

[glwagner]

That said, it can well-motivated in two cases:

1. This package does not actually depend on Oceananigans, and can be used outside of it (I think this is the case for SeawaterPolynomials for example)
2. This package adds significant additional functionality that is not desired in Oceananigans. In that case, having it in a separate package will make loading / using Oceananigans more efficient, when the TripolarGrid is not needed.

I don't think that we meet either of these requirements though --- this package depends on Oceananigans and cannot be used separately from it. Also, this is a rather small package that provides a minor extension to Oceananigans and therefore I don't think significantly adds to Oceananigans bloat.