Add SoilCanopy diagnostics

[AlexisRenchon]

Purpose

This is a second major PR to introduce diagnostics in ClimaLand.

To do:

• Update SoilCanopyModel weekly long run with :long output_vars - test if it works!
• docs: optional kwarg output_vars = :short or :long --> write it so it is called and written in docs, output_period = :hour or :month or ...
• add diagnostics to experiments/integrated/global/global_soil_canopy.jl, plots like Bucket, make sure it is grabbed by buildkite
• macro to reduce code duplication in compute_ and add_diag ( ? )
• fix names, units, comments of SoilCanopyModel diagnostics variables
• add more default methods, period of averaging, what variables, etc.
• Update where variable are stored if needed, add SIF

next PR 1:

• Add @has_error macro
• Somewhere, say which variable is 2D and which one is 3D (i.e., which has depth)
• 2nd round of names, units, comment etc. review, address the one still WIP in this PR (that need further discussion with Renato and Kat)
• Kat: we also have some runoff variables, but where or not they are present depends on the type of RunoffModel we choose. maybe this is something we can accomodate? E.g. NoRunoff() has no additional variables, while TopModel has subsurface, surface runoff in p.soil
• Make sure carbon flux units are consistent, and chose: mol co2 m-2 s-1? Co2 or c? mol or kg?

next PR 2:

• more tests
• better docs
• use diagnostics in all files (need to update experiments, tests, etc.)
• Add land-sea mask as output by default, might be in the domain? (where to compute it? --> ask Kat)

next PR 3:

• use actual months Add support for calendar periods ClimaDiagnostics.jl#67

[AlexisRenchon]

@kmdeck
@braghiere

Could you just look at:
land_compute_methods.jl - do I have everything we compute in p and Y? Does the code organization look good?

define_diagnostics.jl - Are the names, units and comments good? You can start at line 182 (SoilCanopyModel)

[AlexisRenchon]

@kmdeck @Sbozzolo

Should we add a test that check if all variables of a model (e.g., SoilCanopyModel) are defined in the diagnostics?
That would be good to ensure in CI that if we add a new variable, it has to be in diagnostics

[Sbozzolo]

@kmdeck @Sbozzolo

Should we add a test that check if all variables of a model (e.g., SoilCanopyModel) are defined in the diagnostics? That would be good to ensure in CI that if we add a new variable, it has to be in diagnostics

There is no requirement for variables defined to be in the model to be in the diagnostics too: only those that are scientifically interesting

[kmdeck]

we also have some runoff variables, but where or not they are present depends on the type of RunoffModel we choose. maybe this is something we can accomodate? E.g. NoRunoff() has no additional variables, while TopModel has subsurface, surface runoff in p.soil

[AlexisRenchon]

I think this is fine - user decide which diagnostic variable to get, so we can put runoff here, and then user can grab it or not...
For the default, I will think about how to handle this, I am not sure

[kmdeck]

I think this may be kg of C.
I think we have a bug in the units in the code. Maybe worth fixing in this PR?
https://github.com/CliMA/ClimaLand.jl/blob/main/src/standalone/Vegetation/canopy_parameterizations.jl#L1004 [maintenance is in kg/m^2/s]
but here it is used with An: https://github.com/CliMA/ClimaLand.jl/blob/main/src/standalone/Vegetation/canopy_parameterizations.jl#L1040
and An has units of mol CO2.

[AlexisRenchon]

I think it would be good to decide together what to do with flux of CO2 @braghiere , do we express them is mol CO2, kg C, or other?
These are all SI, so we just have to pick one.
Usually, in the literature, we use mol CO2 for fluxes (umol), and kg C for budgets (change in pool size or pool size).
I would vote for mol CO2, but let's all agree.

[braghiere]

Yep. Carbon fluxes is usually in umolCO2.m-2.s-1 (or kgCm-2-day-1) and pools are in kgC.