Reformatting to separate Oceananigans

[jagoosw]

I've not really started doing this yet because I've been trying to test the particle updating in the kelp branch (and had to fix boundary enforcement in Oceananigans) but I think the easiest way to do this would be to remove the setup functions from the model files and just have the forcing functions (and anything else model specific). Then somewhere else define functions like BGC.Oceananigans(grid, model, params, forcing_functions), and another BGC.BoxModel(model, params, forcing_functions). Do we like this structure?

Also, for a box model what happens to the detritus sinking? Do we just remove that term completely and have the detritus build up?

Finally, I think Oceananigans will still have to be a dependency because I don't think theres a way to setup optional dependencies for a package, but this means users would never have to run anything from it.

[johnryantaylor]

I like this idea of separating the box model and oceananigans setup scripts. Regarding detritus in a box model, it depends on the application. E.g. of the box model represents the mixed layer, then it would make sense to have a flux of detritus out the bottom of the box. This could be done with a term like -w_d*d on the rhs of the d equation. It’s fine to keep the oceananigans dependency. The main issue would be lots of details in the setup script that might confuse people who aren’t using oceananigans.

…

On Jul 26, 2022, at 5:01 AM, Jago Strong-Wright ***@***.***> wrote:  I've not really started doing this yet because I've been trying to test the particle updating in the kelp branch (and had to fix boundary enforcement in Oceananigans) but I think the easiest way to do this would be to remove the setup functions from the model files and just have the forcing functions (and anything else model specific). Then somewhere else define functions like BGC.Oceananigans(grid, model, params, forcing_functions), and another BGC.BoxModel(model, params, forcing_functions). Do we like this structure? Also, for a box model what happens to the detritus sinking? Do we just remove that term completely and have the detritus build up? Finally, I think Oceananigans will still have to be a dependency because I don't think theres a way to setup optional dependencies for a package, but this means users would never have to run anything from it. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[jagoosw]

Okay that makes sense, I will probably do this tomorrow.

For the LOBSTER model:

• Since the DIC/ALK aren't depended on by anything else should I make them optional?
• When I've been trying to find a simple sediment model they all depend on the oxygen concentration. In this paper they extend LOBSTER to include the oxygen so I think the simplest option is to add this as another optional tracer?

[jagoosw]

Think I've pretty much finished this now. I'm not sure what I can compare against for the box model but here is what I get from the example.

I've also finished the reformatting and will merge (#7) this afternoon after I've checked it (@syou83syou83, because I've change how you set up the model this will break any existing uses of it a little bit).