Renaming HydrostaticBoussinesqModel to HydrostaticBoussinesqEquations

[glwagner]

1723 proposes a new type called HydrostaticBoussinesqSuperModel that's intended to be more general than HydrostaticBoussinesqModel, because it encapsulates information about the continuous underlying equations, the spatial discretization, and the temporal discretization.

I think we should also then rename HydrostaticBoussinesqModel (a BalanceLaw) to HydrostaticBoussinesqEquations, so that we can use HydrostaticBoussinesqModel for this more general object. The hope is that the current "SuperModel" more closely corresponds to the term "model" as used in the geosciences (eg the entire software package MITgcm is referred to as an "ocean model").

@blallen what do you think?

[kpamnany]

@simonbyrne -- AtmosModel -> AtmosEquations?

[charleskawczynski]

I think the name switch is fine, but I think we should maintain a layer at which we have a continuous representation of the equations.

[glwagner]

I agree, it's very nice to have a single object that abstracts the concept of the continuous equations and I suppose right now this object is either called a "BalanceLaw" or *Model. But since the object represents partial differential equations, or systems of equations, struct HydrostaticBoussinesqEquations <: BalanceLaw could also make sense. Then we can use the word "model" to mean something closer to what the UQ folks call a "model" (something that takes numbers as input and spits out numbers, thus requiring both spatial and temporal discretization).

I'm worried how this shakes out for non-fluids equations. At the end of the day the "soil balance law" is presumably also a system of partial differential equations (otherwise it could not be implemented with BalanceLaw?) but this may not be common terminology.

AtmosModel or AtmosEquations are somewhat non-specific --- but perhaps that avoids boilerplate (rather than something like CompressibleNavierStokesEquations or AnelasticEquations?

[glwagner]

I guess as a side note, and using SuperModel as the name for this super object, is it possible to use an abstraction where one can use the patterns

# For LES
domain = CartesianDomain()
equations = CompressibleNavierStokesEquations(...)

model = AtmosSuperModel(domain=domain, equations=equations)

# For GCM
domain = SphericalDomain(mesh=CubedSphere())
equations = AnelasticEquations(...) # (?)

model = AtmosSuperModel(domain=domain, equations=equations)

You can also provide convenience constructors which provide a flatter interface

model = AtmosCompressibleSuperModel(
    domain=domain,
    # compressible parameters / types
)

if need be.

[christophernhill]

I guess as a side note, and using SuperModel as the name for this super object, is it possible to use an abstraction where one can use the patterns

# For LES
domain = CartesianDomain()
equations = CompressibleNavierStokesEquations(...)

model = AtmosSuperModel(domain=domain, equations=equations)

# For GCM
domain = SphericalDomain(mesh=CubedSphere())
equations = AnelasticEquations(...) # (?)

model = AtmosSuperModel(domain=domain, equations=equations)

You can also provide convenience constructors which provide a flatter interface

model = AtmosCompressibleSuperModel(
    domain=domain,
    # compressible parameters / types
)

if need be.

@glwagner etc... any thoughts on how this would look for coupled systems that are a union of several model/supermodel entities. It feels to me like a SuperModel might want to be thought of as a union of one or more SuperModels. Would it make sense to think of that way? Or do we have a model foo that is the union of one or more model foos and a SuperModel is more like Main and there really is only one SuperModel and its context.

This probably doesn't really affect much practical except thinking right now (and feels a little angels on head of a pin ish given we mostly need robustly working models!) - but it might be good to have something in mind for future and it could be useful and practical too.

[glwagner]

I'm not entirely sure about coupled models. I think the ideal code would be flexible enough that the subcomponents could be lifted right out of the box and into a coupled framework, eg

ocean_domain = SphericalDomain(...)
atmos_domain = SphericalDomain(...)
ocean_model = HydrostaticBoussinesqSuperModel(domain=ocean_domain)
atmos_model = CompressibleSuperModel(domain=atmos_domain)

coupled_model = CoupledAtmosOceanSuperModel(ocean=ocean_model, atmos=atmos_model, coupler=AtmosOceanCoupler(...))

(A la this discussion I'm not sure SuperModel is best, we could just use Model, or some other word like Simulator.) Not sure that's possible in practice.

It'd be nice to have a concise interface for ocean and atmos independently, since that would make creative work with coupled models, including limited-area coupled models, a lot easier.

Pretty futuristic right now though. But I think regardless we can probably assume that the easier and more logical it is to specify a subcomponent experiment, the easier it will be to specify a coupled model experiment.

[simonbyrne]

I agree that we abuse the term Model a bit too much (mostly that is my fault). I'm okay with Equations (or perhaps a short form Eqns?)

• I think keep it as AtmosEquations (or AtmosEqns?) at the moment: while the core dynamics are Navier-Stokes, we have more stuff in there (turbulence closures, moisture, etc). If we have an alternative atmosphere equation set (e.g. hydrostatic) then we can worry about the distinction then.

• We should probably rename DGModel as well, maybe DGDiscretization?

[glwagner]

I think non-abbreviated names read better, but ultimately fine with either Equations or Eqns.

Not sure what other physicists say, but I think its valid to say that we solve Navier-Stokes. We just add extra terms that either approximate physics that are additional to Navier-Stokes (like moisture) or that model parts of the fluid motion we can't resolve with our coarse, discrete approximations (like turbulence closures). Ultimately, turbulence closures are attempting to model at least some of the physics of the Navier-Stokes equation, somehow.

I actually think that it's nice to use the term Navier-Stokes. It signals to a broad community (fluid dynamicsts, engineers, not just earth scientists) that there's something familiar (u . grad(u)) going on somewhere inside, and could invite such people to explore.

For ocean stuff I guess we are choosing Boussinesq as a replacement for Navier-Stokes, which describes a crucial simplification we make to approximate the effect of the ocean's variable density.

[blallen]

For ocean stuff I guess we are choosing Boussinesq as a replacement for Navier-Stokes, which describes a crucial simplification we make to approximate the effect of the ocean's variable density.

We could call them the HydrostaticBoussinesqNavierStokesEquations but that doesn't even abbreviate well HBNSEquations or HBNSE.

I think the renaming of *Model to *Equations is good overall. I know no one wants to change BalanceLaw, but we could also rename that to EquationSet or something similar. Distinguishing between the PDE level and the full solver/model/simulation level is good.

[glwagner]

Since BalanceLaw isn't user-facing I think it's less important (but still 😏).

[blallen]

I agree that we abuse the term Model a bit too much (mostly that is my fault). I'm okay with Equations (or perhaps a short form Eqns?)

• We should probably rename DGModel as well, maybe DGDiscretization?

Yes! DGModel should definitely not be called a full model :) Discretization is a good description, maybe we can come up with something better?

[glwagner]

I think SpatialDiscretization as a shortened version of SpatiallyDiscretizedBalanceLaw might be accurate. It looks like the type contains information pertinent to the spatial aspects of a discrete approximation to a partial differential equation.

Using DG might not be necessary. That can be inferred by context. Unless we plan on supporting other discretization methods.

Note though this is slightly out of scope for this issue.

[kpamnany]

Cc: @kmdeck