Purpose

The goal of this SDI is to describe the steps needed to be able to drive the soil model with prescribed atmospheric conditions and prescribed radiation (MO surface fluxes SF and radiation R).

I think this is a valuable use case to be able to run. There are data for soil evaporation, for example, which it would be nice to compare with.

Whether or not we would find it useful to couple just the soil model the atmosphere is another question. I dont think this is necessarily a use case of interest, but this would allow that as well.

Cost/benefits/risks

This is about a week of concentrated work for one developer but Ive already done most of it...so low cost
Benefit is more functionality for soil and generality in how we handle prescribed atmosphere and radiation simulations. I think the wrapper functions that we will develop for computing SF and R will be useful.
Risk is that this may be a somewhat niche application.

Producers

@kmdeck reviews by @juliasloan25

Components

1. Make it so the soil model computes fluxes per boundary (water and energy at the same time) rather than per boundary per variable.
2. Make it so the soil model can use the driver functionality in SharedUtilities/drivers.jl (which works already with Snow and the Bucket)
3. Run the soil model with these driver functions.
4. Add in soil conductivity
5. Add in sublimation

Inputs

We need to supply T_sfc, q_sfc, rho_sfc, resistance, albedo, and emissivity for the soil model, then we can call the same functions we have already been calling. the design doc has the equations we want to use. we'd start with constant emissivity and albedo.

Results and deliverables

We should be able to let wet soil evaporate with constant atmospheric conditions and see the correct stages of evaporation. We can compare with data. However, we would need to modify the output of SF.jl to account for soil resistance. we can do that for now, but in the long term this has to live in SF.jl.

Task breakdown

A preliminary list of PRs and a preliminary timeline of PRs, milestones, and key results.

• Compute boundary fluxes at each boundary, rather than by component #156 Right now the soil mode computes boundary conditions per component per boundary (water, energy, top, bottom). To avoid two calls to surface fluxes, we should compute boundary conditions per boundary, and return all of the component boundary fluxes.
• Generalize the driver interface #160 We have some shared utility types and functions for compute surface fluxes and net radiation (SharedUtilities/drivers.jl). However, as written, they wont work for the soil model, because the soil model does not in general store T_sfc, q_sfc, and rho_sfc in the aux state (and as our code base currently works, it cannot do so, because those live on a different domain than the rest of the soil variables). It seems like the next best thing is to make wrapper functions for the quantities needed by surface fluxes and the RT module.
• Soil climate drivers #170 Create a Prescribed BC type for soil, and call the utility functions in the RHS.
• add soil resistance #184 184 Add in soil resistance
• Sublimation #373 Add in soil sublimation
  ...

Reviewers

@juliasloan25