ClimaOcean.jl
ClimaOcean.jl copied to clipboard
Add biogeochemistry interface to ocean_simulation
- At minimum this requires adding a
biogeochemistrykwarg to theocean_simulationfunction (the BGC model can be initialised beforehand with the grid):
https://github.com/CliMA/ClimaOcean.jl/blob/514135fc9a1016ec0c32081fe3914e789b3d35ca/src/OceanSimulations/OceanSimulations.jl#L55-L68
-
A way to pass BGC boundary conditions (e.g. surface air-sea CO2 flux) and merge with existing
ocean_boundary_conditions, and ideally also a way to pass through custom BGC forcings -
Also I think the BGC tracers that are defined within the biogeochemistry model need to be added to tracers for tracer_advection? Could perhaps extract the tracers initialised in the BGC model using
Oceananigans.Biogeochemistry.required_biogeochemical_tracers(biogeochemistry)and merge with existingtracers?
cc @glwagner @jagoosw
Boundary conditions are hard coded here:
https://github.com/CliMA/ClimaOcean.jl/blob/514135fc9a1016ec0c32081fe3914e789b3d35ca/src/OceanSimulations/OceanSimulations.jl#L77-L80
As for tracers, there's a sort-of-ongoing discussion about whether we should add bgc tracers automatically or not. We could definitely do that for ocean_simulation but I think it'd be best to take the same approach that we take in Oceananigans (for example, we could also add them automatically in Oceananigans). Just to minimize confusion / dissonance between the user interfaces. Any thoughts about adding them automatically vs not? We had reasoned that requiring the tracers to be explicitly spelled out made scripts easier to understand. And while slightly more inconvenient to write, the fact is that users of bgc need to know what the tracers are called anyways for output, initial conditions, etc.
Boundary conditions are hard coded here:
https://github.com/CliMA/ClimaOcean.jl/blob/514135fc9a1016ec0c32081fe3914e789b3d35ca/src/OceanSimulations/OceanSimulations.jl#L77-L80
Couldn't ocean_simulation just have a kwarg e.g. custom_boundary_conditions and then a line like:
ocean_boundary_conditions = merge(ocean_boundary_conditions, custom_boundary_conditions)
@glwagner that's helpful context. I think for consistency that makes sense to not add them automatically, and I agree with your reasoning. ocean_simulation doesn't currently have a tracer kwarg as T and S are hardcoded as tracers, so this will need to be added to pass through the BGC tracers?
For boundary conditions I was thinking the same as what @jagoosw suggested (that's what I've been doing with test runs of the old near global setups).
Boundary conditions are hard coded here: https://github.com/CliMA/ClimaOcean.jl/blob/514135fc9a1016ec0c32081fe3914e789b3d35ca/src/OceanSimulations/OceanSimulations.jl#L77-L80
Couldn't
ocean_simulationjust have a kwarg e.g.custom_boundary_conditionsand then a line like:ocean_boundary_conditions = merge(ocean_boundary_conditions, custom_boundary_conditions)
Yes although I want to think about the name, I'm not sure custom_boundary_conditions is best. Maybe just boundary_conditions. Also it would be nice if we only replace the boundary conditions we have to, ie we keep the surface fluxes of T, S even if we need to use user-supplied T or S conditions at the bottom or on immersed boundaries.
@vtamsitt do you want to have a crack at it or do you want me to open a PR?
I'll have a crack!