Add Grids, make them mutable objects

[simonbyrne]

Fixes #1120 and #1467.

I've gone with option 2 in #1120 (comment).

In the following benchmark:

using ClimaComms

import ClimaCore:
    ClimaCore,
    slab,
    Spaces,
    Domains,
    Meshes,
    Geometry,
    Topologies,
    Spaces,
    Fields,
    Operators


FT = Float64
vertdomain = Domains.IntervalDomain(
    Geometry.ZPoint{FT}(0.0),
    Geometry.ZPoint{FT}(1.0);
    boundary_tags = (:bottom, :top),
)
vertmesh = Meshes.IntervalMesh(vertdomain, nelems = 10)
vert_center_space = Spaces.CenterFiniteDifferenceSpace(vertmesh)

horzdomain = Domains.SphereDomain(30.0)
horzmesh = Meshes.EquiangularCubedSphere(horzdomain, 4)
horztopology = Topologies.Topology2D(
    ClimaComms.SingletonCommsContext(ClimaComms.CPUSingleThreaded()),
    horzmesh,
)
quad = Spaces.Quadratures.GLL{3 + 1}()
horzspace = Spaces.SpectralElementSpace2D(horztopology, quad)

hv_center_space =
    Spaces.ExtrudedFiniteDifferenceSpace(horzspace, vert_center_space)

coords = Fields.coordinate_field(hv_center_space)
x = Geometry.UVWVector.(cosd.(coords.lat), 0.0, 0.0)


t = ntuple(i -> x, 80);
f(t) = t
@time f(t);

On main:

julia> @time f(t);
  1.455831 seconds (343 allocations: 24.953 KiB, 100.00% compilation time)

on this branch

julia> @time f(t);
  0.002401 seconds (343 allocations: 24.953 KiB, 99.12% compilation time)

• Code follows the style guidelines OR N/A.
• Unit tests are included OR N/A.
• Code is exercised in an integration test OR N/A.
• Documentation has been added/updated OR N/A.

[Sbozzolo]

With regards to integration in ClimaAtmos, I had this in mind: CliMA/ClimaAtmos.jl#2147

I also defined some Grid objects that are directly relevant to the most common applications in ClimaAtmos

[simonbyrne]

@Sbozzolo for ClimaAtmos, could we just use the ClimaCore grid objects directly?

[Sbozzolo]

@Sbozzolo for ClimaAtmos, could we just use the ClimaCore grid objects directly?

I think we should have simple and physically-relevant objects in ClimaAtmos. The computational grid is one of the main players in a simulation, and I think that the ClimaCore grids are still too low level. I think that it should be easy to know if I am simulating a sphere or a plane and get the relevant properties (How many points do I have? What is the physical extent? What is the radius of the sphere?)

In ClimaAtmos, we care about 4 configurations (x2 depending if your vertical resolution is constant or not):

• sphere
• box
• plane
• column

For 2 of these 4, we want to support topography and optionally enable the bubble correction. These are clearly distinct
cases that have implications for the rest of ClimaAtmos. For example, there are flags that are automatically turned on/off for some cases, and now we are relying on manually checking parsed_args. In addition to this, building the various cases requires specialized code that is purview of ClimaAtmos, so I think that there are good reasons to add another level of abstraction in ClimaAtmos.

[simonbyrne]

We could probably define type aliases that would allow you to do dispatch, e.g.

const ExtrudedCubedSphereGrid = ExtrudedFiniteDifferenceGrid{<:SpectralElementGrid2D{<:Topology2D{<:ClimaComms.AbstractCommsContext, <:AbstractCubedSphereMesh}}}

[simonbyrne]

If it would help, we could make this simpler by making the lower level objects (domain, mesh) fields of the grid as well?

[simonbyrne]

bors try

[bors]

try

Build failed:

• buildkite/climacore-ci

[bors]

try

Build failed:

• buildkite/climacore-ci

[simonbyrne]

bors try

[bors]

try

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• format
• test-os (windows-latest)
• lib-climacore-makie
• test-os (ubuntu-20.04)
• lib-climacore-vtk
• lib-climacore-plots
• lib-climacore-tempestremap
• buildkite/climacore-ci
• docbuild

[simonbyrne]

Okay, we're passing here and on ClimaAtmos: https://buildkite.com/clima/climaatmos-ci/builds/14490#018b76ad-a266-4930-afb5-7d104496ae6b

[charleskawczynski]

Can we document (or provide a link to docs to show) what @memoise WeakValueDict is doing here? or somewhere?

[charleskawczynski]

Can/should we instead move _configure_threadblock to _configure_threadblock a separate file or something?

[simonbyrne]

what do you mean?

[charleskawczynski]

_configure_threadblock doesn't really have anything to do with Topologies

[charleskawczynski]

Overall, the changes look good, and I want to slow this down given the quality of life improvement it brings!

[charleskawczynski]

And thanks for testing in CliMA Atmos!