There's been a bunch of interest in using Oceananigans for physical-biogeochemical interaction studies --- problems where systems of reacting tracers that represent either oceanic biological systems, chemical reactions and cycles, or both interact with turbulence and fluid dynamics simulated by Oceananigans.
In order to organize the community's work (and also to support some work at Clima on biogeochemistry in Oceananigans), I propose that we create a new package that interfaces with Oceananigans --- could it be... Biogeoceananigans.jl... ? --- to:
- Facilitate sharing code, and collaboration on implementation and testing of biogeochemistry models to be used in Oceananigans simulations
- Develop documentation and a suite of examples to illustrate usage, setup, and analysis of numerical experiments with biogeochemistry
To achieve either of these there's no question we need a particular place to collaborate on re-useable code (rather than working independently). But also, I think the Oceananigans.jl repository is not the best repo to use to achieve the above goals, because it's big and complex, which might make it harder for potential developers to contribute and see their place. I also think it would slow development down, because, for example, we'll have to make sure all unit tests for differential operators pass before we can add a new biogeochemistry model implementation. I think development might be faster and more accessible if we do it in a different repo.
There are also some details to discuss regarding implementation. Oceananigans' design already supports reacting systems via Forcing. Oceananigans Forcing are arbitrary functions of spatial coordinates, time, prognostic model fields, and forcing function parameters --- or alternatively, indices i, j, k, grid, clock, and a NamedTuple of model fields that can be indexed into arbitrarily. @iuryt and @syou83syou83 (and perhaps others) have experimented in this direction.
However, I think we might benefit from adding a model property to both NonhydrostaticModel and HydrostaticFreeSurfaceModel that's specifically dedicated to biogeochemistry, and designing an interface that allows users / other packages (like Biogeoceananigans.jl) to build custom biogeochemistry types. One advantage I think is we'll have more flexibility in designing the code that hooks into Oceananigans than if we limit ourselves to using model.forcing. I also think it will yield a cleaner and more interpretable user API: biogeochemistry models are sometimes complicated, so it's helpful to disentangle their specification from the specification of more "vanilla" forcing terms, like sponge layers, etc. We may want special time-stepping methods for some types of biogeochemistry in the future.
I also think we can build an interface for biogeochemistry that uses similar or identical syntax to Forcing (like requiring functions of x, y, z, t, fields --- etc) because this will allow directly transferring code for biogeochemistry models that's first implemented as a system of forcing functions (a very common and useful development paradigm).
What do others think about this? @iuryt @johnryantaylor @rafferrari @simone-silvestri @christophernhill @jm-c @sandreza
There's been a bunch of interest in using Oceananigans for physical-biogeochemical interaction studies --- problems where systems of reacting tracers that represent either oceanic biological systems, chemical reactions and cycles, or both interact with turbulence and fluid dynamics simulated by Oceananigans.
In order to organize the community's work (and also to support some work at Clima on biogeochemistry in Oceananigans), I propose that we create a new package that interfaces with
Oceananigans--- could it be...Biogeoceananigans.jl... ? --- to:To achieve either of these there's no question we need a particular place to collaborate on re-useable code (rather than working independently). But also, I think the Oceananigans.jl repository is not the best repo to use to achieve the above goals, because it's big and complex, which might make it harder for potential developers to contribute and see their place. I also think it would slow development down, because, for example, we'll have to make sure all unit tests for differential operators pass before we can add a new biogeochemistry model implementation. I think development might be faster and more accessible if we do it in a different repo.
There are also some details to discuss regarding implementation. Oceananigans' design already supports reacting systems via
Forcing. OceananigansForcingare arbitrary functions of spatial coordinates, time, prognostic model fields, and forcing function parameters --- or alternatively, indicesi, j, k,grid,clock, and a NamedTuple of model fields that can be indexed into arbitrarily. @iuryt and @syou83syou83 (and perhaps others) have experimented in this direction.However, I think we might benefit from adding a model property to both
NonhydrostaticModelandHydrostaticFreeSurfaceModelthat's specifically dedicated tobiogeochemistry, and designing an interface that allows users / other packages (like Biogeoceananigans.jl) to build custombiogeochemistrytypes. One advantage I think is we'll have more flexibility in designing the code that hooks into Oceananigans than if we limit ourselves to usingmodel.forcing. I also think it will yield a cleaner and more interpretable user API: biogeochemistry models are sometimes complicated, so it's helpful to disentangle their specification from the specification of more "vanilla" forcing terms, like sponge layers, etc. We may want special time-stepping methods for some types of biogeochemistry in the future.I also think we can build an interface for
biogeochemistrythat uses similar or identical syntax toForcing(like requiring functions ofx, y, z, t, fields--- etc) because this will allow directly transferring code for biogeochemistry models that's first implemented as a system of forcing functions (a very common and useful development paradigm).What do others think about this? @iuryt @johnryantaylor @rafferrari @simone-silvestri @christophernhill @jm-c @sandreza