ClimaOcean.jl icon indicating copy to clipboard operation
ClimaOcean.jl copied to clipboard

Add biogeochemistry interface to ocean_simulation

Open vtamsitt opened this issue 1 year ago • 6 comments

  1. At minimum this requires adding a biogeochemistry kwarg to the ocean_simulation function (the BGC model can be initialised beforehand with the grid):

https://github.com/CliMA/ClimaOcean.jl/blob/514135fc9a1016ec0c32081fe3914e789b3d35ca/src/OceanSimulations/OceanSimulations.jl#L55-L68

  1. 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

  2. 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 existing tracers?

cc @glwagner @jagoosw

vtamsitt avatar Jul 30 '24 23:07 vtamsitt

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.

glwagner avatar Jul 31 '24 15:07 glwagner

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)

jagoosw avatar Jul 31 '24 16:07 jagoosw

@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).

vtamsitt avatar Jul 31 '24 17:07 vtamsitt

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)

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.

glwagner avatar Jul 31 '24 18:07 glwagner

@vtamsitt do you want to have a crack at it or do you want me to open a PR?

glwagner avatar Jul 31 '24 18:07 glwagner

I'll have a crack!

vtamsitt avatar Jul 31 '24 19:07 vtamsitt