O2.3.5 Enable global runs (on GPU)

[juliasloan25]

Is your feature request related to a problem? Please describe.
We want to be able to run ClimaLSM globally. To do this, there are a few structural changes we need to make first.

Main changes

1. need global prescribed atmosphere
2. forcings over the globe read in from files
3. spatially-varying quantities over the globe

1. unified interface for site and global prescribed atmosphere types (see #451)

• we have: a PrescribedAtmosphere type (src/shared_utilities/drivers.jl) which can be used at a point. This holds things like atmospheric CO2, wind speed, pressure, etc
• we need: a way to extend this struct to run either at the site-level or globally
• potential solution:
  • Interpolators module implementing unified interface for all cases (analytic drivers, site-level drivers from data, global drivers from data, (prescribed atmos driver?)). This will isolate the differences between each case to the back-end internals, and avoids the need for a new PrescribedAtmos type

2. forcings over the globe - store these in p and update via callback (see #370)

• we have: forcings stored in PrescribedAtmosphere
• we need: to move some forcings to p. When we update these, we'll dispatch off of the PrescrAtmos type, to read in fields over the sphere when running global and just evaluate a function when running at a column.
• the reason for this change is that, in the global case, the forcings will be Fields over the sphere that we want to allocate for once and update over time, instead of allocating on-the-fly as we do with column simulations currently
• potential solution:
  • add field p.forcings containing sw_in, lw_in, P, T, q, etc
  • add function update_forcings to update these values. This will dispatch off of PrescrAtmos type (as described above)
  • call update_forcings before update_aux and update_interactions to update in correct order

3. spatially-varying parameters read in over time globally (See #126)

• we have: albedo as a first example (BulkAlbedoSpatial and BulkAlbedoTemporal types)
• we need: analogous types for other quantities
  • soil porosity, vg params, lai, canopy height, vcmax, etc
    @kmdeck @braghiere

4. Handle file IO

prescribed atmos/forcings/parameters infrastructure

Beta Give feedback

1. Remove splines, add TimeVaryingInputs #451
   API GPU breaking change enhancement +4
2. Add global bucket runs with albedo maps #477
   enhancement +1
   
3. Spatially varying parameter #126
   enhancement +1
   

GPU compatibility + performance

Beta Give feedback

1. Add GPU compatibility in ClimaLSM #392
   GPU SDI +2
   
2. Add target GPU run #587
   enhancement +1
   
3. Performance roadmap #586
   8 of 9
   +0
   

Add target run

Beta Give feedback

1. Add global soil/canopy run forced by ERA5 data, with 1 degree resolution and reading in data every 3 hours #644
   4 of 4
   +0
   

[kmdeck]

Hi Julia,

thanks for putting this together. Some small comments/questions:

• we can make use of this: https://github.com/CliMA/ClimaLSM.jl/blob/bf1e03a5389df85409451eecf2d5ac7cda3c793a/src/shared_utilities/drivers.jl#L23 and https://github.com/CliMA/ClimaLSM.jl/blob/bf1e03a5389df85409451eecf2d5ac7cda3c793a/src/shared_utilities/drivers.jl#L34. For now, Im inclined to leave these as separate quantities but maybe it makes sense to combine in the future?
• can we make use of these types youve defined for the forcings too? https://github.com/CliMA/ClimaLSM.jl/blob/bf1e03a5389df85409451eecf2d5ac7cda3c793a/src/shared_utilities/FileReader.jl#L22

more major question

• If we have ~10 fields changing in time, every hour, for 1 year, over ~ half the globe at 50kmx50km, we would have 1024365*(4pi6376^2/50^2)/2 = 9 billion numbers, or 0.5 TB of data if they are Float64. Our timestep might be at best ~10-30 minutes, so we dont have a clear separation between the timestep and how often we need to read in data. So both reading in all the data and storing it in advance and reading in once per hour of simulation time are both tricky. Before implementing, it might be good to make sure we understand what other land models do, and to run by @Sbozzolo

[kmdeck]

SLIM is a model quite like our bucket model which can be run in standalone or coupled: https://github.com/marysa/SimpleLand

[braghiere]

Can we add info about the ocean mask here? I.e., a way to save time in calculations by avoiding running the land model over the oceans. The advantage of the land models in comparison to atmos or oceans is that we can run the model in single grid cells.

[juliasloan25]

I asked @simonbyrne about this, and he said there isn't yet a plan to add this in to ClimaCore, and that implementing this will depend on what type of grid ClimaLSM uses going forward

[braghiere]

What do you mean by type of grid? It is usually regular grids, i.e., 0.25deg, 0.50 deg, 1.0deg, 2.0deg, lats and lons have same shape and the globe is divided into squares.

[kmdeck]

many details point 2 can be found here #370 (SDI)