Easy to mess up when setting boundary conditions via model constructor

[glwagner]

Just to share an experience I just had...

More or less I set up a model with

model = IncompressibleModel(grid = grid, boundary_conditions = (κₑ=(T=κₑ_T)))

and was surprised when the boundary conditions were not set on diffusivity. Why? Because I forgot a comma: the line

boundary_conditions = (κₑ=(T=κₑ_T)) # wrong

should be

boundary_conditions = (κₑ=(T=κₑ_T,)) # correct

In other words, the field κₑ must be a NamedTuple to work correctly. I think #wrong version essentially parses as κₑ=T=κₑ_T, so that κₑ is a FieldBoundaryCondition rather than a NamedTuple of FieldBoundaryConditions.

We could potentially do some checking as a band-aid. But in general, I think this is a tough problem and I don't have too many bright ideas on how to make this elegant and intuitive. So perhaps we can discuss here.

[glwagner]

Mostly I am worried about scalability and sustainability in this design, or future designs.

Currently our models are fairly simple, but its challenging to place bounds on potential future complexity. For example, models in the future may require additional fields associated with closures or parameterizations, such as boundary layer depth fields, in-plume tracer concentrations and vertical momentum, precomputed mixing length fields, and perhaps other auxiliary fields associated with various prognostic / diagnostic LES models. We probably can't plan to support setting boundary conditions on every possible field via the model constructor.

With our current design we have essentially special-cased turbulent diffusivities because our focus is LES, turbulent diffusivities are relatively common, and it convenient for us. However doing this incurs some maintenance burden --- which will increase if we plan to hard-code validation and error checking.

Food for thought.

[johncmarshall54]

Greg, Ali, and what if we began to consider more complex geometries etc - hard to resist going in that direction..... we'd have to change the solvers

• more MITgcm-like, congrad etc - but what would the implications be for boundary conditions? More food for thought. John

On Sat, Mar 28, 2020 at 10:22 AM Gregory L. Wagner notifications@github.com wrote:

Mostly I am worried about scalability and sustainability in this design, or future designs.

Currently our models are fairly simple, but its challenging to place bounds on potential future complexity. For example, models in the future may require additional fields associated with closures or parameterizations, such as (two-dimensional) boundary layer depth fields, plume quantities, mixing lengths and perhaps other auxiliary fields associated with various prognostic / diagnostic LES models. We probably can't plan to support setting boundary conditions on every possible field via the model constructor.

With our current design we have essentially special-cased turbulent diffusivities because our focus is LES, turbulent diffusivities are relatively common, and it convenient for us. However doing this incurs some maintenance burden --- which will increase if we plan to hard-code validation and error checking.

Food for thought.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/climate-machine/Oceananigans.jl/issues/721#issuecomment-605453798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKXUEQT642WME2EIX3DDSITRJYBYXANCNFSM4LVSZPAA .

--

John Marshall Cecil and Ida Green Professor of Oceanography Massachusetts Institute of Technology http://oceans.mit.edu/JohnMarshall/

[glwagner]

@johncmarshall54 agreed, that's a challenge we have to confront.

If we implement immersed boundaries using the "continuous forcing technique", then a boundary may be defined essentially by a masking function of (x, y, z) (it is also possible for it to be a function of time). In this case, we might be able to "label" each boundary / masking function with a name or number.

The boundary condition objects we then give to fields would have to define a condition to be applied both at the boundaries of the numerical grid (which we currently support), as well as any immersed boundaries, where immersed boundaries are referenced by name or number.

By the way, if we use a continuous forcing technique, we do not have to change the pressure solver. This is a major simplification. Recent work suggests there is no disadvantage in terms of accuracy in using the continuous forcing technique over discrete forcing techniques (which I think is the category the MITgcm solver falls under). I'm not sure if this is too good to believe or not --- we should discuss and take a deeper look at the literature.

[johncmarshall54]

Greg, I have notes on a 'capacitance method' that we used in qg models in complex geometries in the 1980s. That also would not require us to change the solver. You carry out Green's function calculations in a rectangular region where the delta-functions vorticities are placed at the positions of the irregular boundary within the larger rectangular region. I will look them out. John

On Sat, Mar 28, 2020 at 11:20 AM Gregory L. Wagner notifications@github.com wrote:

@johncmarshall54 https://github.com/johncmarshall54 agreed, that's a challenge we have to confront.

If we implement immersed boundaries using the "continuous forcing technique", then a boundary may be defined essentially by a masking function. In this case, we might be able to "label" each boundary / masking function with a name or number.

The boundary condition objects we then give to fields would have to define a condition to be applied both at the boundaries of the numerical grid (which we currently support), as well as any immersed boundaries, where immersed boundaries are referenced by name or number.

By the way, if we use a continuous forcing technique, we do not have to change the pressure solver. This is a major simplification. Recent work suggests there is no disadvantage in terms of accuracy in using the continuous forcing technique, either. I'm not sure if this is too good to believe or not --- we should discuss and take a deeper look at the literature.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/climate-machine/Oceananigans.jl/issues/721#issuecomment-605461456, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKXUEQQHGXSSKOU7EIXSLBTRJYIVFANCNFSM4LVSZPAA .

--

John Marshall Cecil and Ida Green Professor of Oceanography Massachusetts Institute of Technology http://oceans.mit.edu/JohnMarshall/

[glwagner]

Closing this as there's no path to resolution.