Add support for spatially varying and parameterized model initializers

[bgroenks96]

This PR generalizes the AbstractInitializer interface to allow initializer types to define input variables and tracked parameters. It also adds a LatitudinalClimatology parameterization to replace the user-side soil initializer code currently duplicated across several examples.

Additional changes

• Adds λnodes and φnodes implementations for ColumnRingGrid, extracting the coordinates from the underlying RingGrid
• Fixes a bug in the generic parameters dispatch for AbstractProcess types
• Adds new rules to AGENTS.md regarding plan formatting and forbidding local Enzyme/Reactant test runs

[maximilian-gelbrecht]

I like this. Makes scripts to run the model also easier.

[bgroenks96]

Makes scripts to run the model also easier.

It's also more functional than that. Until now, we didn't really have a good way to run the initializers with spatially varying inputs. I guess we could have done it in user-side code but that leads to the copy-pasta that we already saw with the LatitudinalClimatology initializer.

[bgroenks96]

Maybe this is also interesting for @glwagner; this is why we have initializers written into Terrarium model code rather than offloading it entirely to users. I think this is also more important for land than for atmosphere/ocean because initialization/spin-up schemes are an extremely important part of models with very slow dynamical components, and these schemes often have their own associated parameters that may need to be calibrated, e.g. the QuasiThermalSteadyState for soil temperature.

However, handling of data needed for initialization is still fed through InputSources and is left to the user. No data directly in the model.

[glwagner]

Maybe this is also interesting for @glwagner; this is why we have initializers written into Terrarium model code rather than offloading it entirely to users. I think this is also more important for land than for atmosphere/ocean because initialization/spin-up schemes are an extremely important part of models with very slow dynamical components, and these schemes often have their own associated parameters that may need to be calibrated, e.g. the QuasiThermalSteadyState for soil temperature.

However, handling of data needed for initialization is still fed through InputSources and is left to the user. No data directly in the model.

Can you put these initialization concepts into a function set!(model, kw...) ? This is better: set! can be called anywhere, it is not tied to the constructor.

[bgroenks96]

Can you put these initialization concepts into a function set!(model, kw...) ? This is better: set! can be called anywhere, it is not tied to the constructor.

The Field initializers that are passed to initialize, yes. They are almost directly just forwarded to set!. The only advantage to passing them to initialize is that they will be automatically re-applied when reinitializing the simulation, which I think is nice but not strictly necessary. The user can also opt to invoke set! themselves, so what you suggest is not precluded.

For the initializer types defined within the model, no, I don't think these can be easily expressed with set! because the whole point is that they are actually part of the model, potentially with their own parameters and configuration options.

[glwagner]

Can you put these initialization concepts into a function set!(model, kw...) ? This is better: set! can be called anywhere, it is not tied to the constructor.

The Field initializers that are passed to initialize, yes. They are almost directly just forwarded to set!. The only advantage to passing them to initialize is that they will be automatically re-applied when reinitializing the simulation, which I think is nice but not strictly necessary. The user can also opt to invoke set! themselves, so what you suggest is not precluded.

how do you reinitialize a simulation?

For the initializer types defined within the model, no, I don't think these can be easily expressed with set! because the whole point is that they are actually part of the model, potentially with their own parameters and configuration options.

I didn't understand this, so let me clarify. The user interface that we have implemented in Oceananigans and Breeze is to define set!(model::AtmosphereModel; field_names). This extends set! as applied to individual fields. Within this function one has access to the model.

This is fairly simple for an ocean model but turns out to be quite complicated for an atmospheric model. Breeze's set! supports setting all sorts of variables. It is common to provide some diagnostic field as input rather than the prognostic fields. For example, one can set! relative humidity, but this is not a prognostic field of the model. I could also envision an API like this:

set!(model::TerrariumModel, initializer::CustomInitializer)

there should be no difference between this and whatever is passed to a model constructor... if I understand correctly. Can this be implemented for Terrarium's models?