Component Model/Simulation Abstraction

[jb-mackay]

A coupled model/simulation contains a group of model components that need to adopt a shared interface to be executed by a coupled timestepping scheme. Major pieces of information that these components must provide the coupler include (but are perhaps not limited to):

• model setup
• choice of solver
• callbacks

so that it can execute a sequence of component models each coupling period. It may also explicitly need knowledge of a component's grid & boundary to facilitate the flux exchange, but perhaps there is a clever way to hide this from a user. Furthermore, a coupled model (one that contains the sub-models) should also adopt this interface, giving us composability/nestability as well as a single framework for building and executing models/simulations.

At the moment, we have several implementations of something like this:

• Aleph.jl's Simulation
• Oceananigans.jl's Simulation +Model ( a Simulation wraps a Model implementation which contains the timestepper)
• CouplerMachine.jl's CplModel

DifferentialEquations.jl uses DEIntegrators in a similar manner, and we are interested in mirroring/extending its interface with the coupled timstepper (e.g. solve! and step! functions).

It would be helpful to reconcile these variations in a unified interface (ultimately Aleph?) to minimize user and developer confusion. This issue is meant to prompt conversation about what a model/simulation abstraction should contain and move towards a single solution. @christophernhill @simonbyrne @glwagner @bischtob @sandreza @LenkaNovak

[jb-mackay]

The need for a coupled component model abstraction is not necessary. An implementation of the abstract type CoupledSimulation will contain the component models; for example, an atmos-ocean-land coupled simulation will have fields for each model. These model's will need to define their own step! functions that dispatch accordingly to advance a model in time. In these custom step! calls (part of the coupling adapter code for a given model), it is specified how a particular component model advances. There will still need to be some kind of standardization relating to these component model simulations (so that we can have a single run! interface, e.g.), but this does not need to be specified by the coupler.