Generalise PartialCellBottom?

[josuemtzmo]

Hello,

I'm interested in generalise the PartialCellBottom to include for partial cells of Immersed Boundary on the top of the model. This will be particularly useful in the future to implement ice-shelves.

Currently as far as I know, in Oceananigans, we can have a Grid fitted (left) with a mask or a PartialCellBottom (right) boundaries, exemplified below:

I'm interested to implement to have partial cells both at the bottom and at the top, i.e.,

My initial thought was to add a new function PartialCellTop, however this will only allow to have partial cells at the top or at the bottom. Additionally, it seems to me that a lot of the code will be duplicated.

Thus, I wanted to know if this is of interest, and if it will be better to modify PartialCellBottom to PartialCell to deal with both cases (i.e. Immersed boundary at the top and bottom), likely going through the mask in GridFittedBoundary, but with values smaller than 1 generating a partial cell (I think this is similar to what MITgcm does).

I'm still missing to check how to deal with the pressure once the partial cells on the top are implemented, so happy to discuss that too.

[glwagner]

I agree this is needed.

It will not be like mask for GridFittedBoundary. This is still a "2.5d" concept. It is just that rather than having only bottom_height, there is also a top_height (or whatever we want to call it). We don't want a 3D mask because it is poorly specified for a fundamentally 2.5D concept --- the partial cells are only partial in z which is a key concept to this abstraction.

I suspect we should generalize PartialCell bottom to something like ZPartialCell. We can still have a type alias when isnothing(top), eg

const PartialCellBottom = ZPartialCell{<:Any, Nothing}

(assuming the first type parameter is bottom and the second is top.

However, I am also not sure if such a type alias will be useful. Perhaps only at first, during testing? Because it will mean that we can implement ZPartialCell non-intrusively without changing any existing code.

For sure a key missing piece to be resolved before pursuing this is how to do the dynamics; without that we won't really be able to test the implementation.