Fix land snow

[LenkaNovak]

Currently snow water conservation and visualization are incorrect when snow is applied. These patterns are similar to the dss inconsistency in here, but this needs to be investigated.

ClimaLSM

• some snow fixes were implemented, and will be available in ClimaLSM0.3.3 https://github.com/CliMA/ClimaLSM.jl/pull/330
  • this now contains unit tests that show that snow is conserved when precipitation is non-zero and non uniform evap field
• https://github.com/CliMA/ClimaCoupler.jl/issues/433

DSS

• using the MWE below (to be run from the Coupler), it can be seen that large errors arise when the input evaporation is a nonuniform field. May this be due to dss? Otherwise the Bucket model is columnwise (i.e. no horizontal exchanges)

Results:

# uniform:
# julia> extrema( @. diff_PE + diff_WL) = (-5.684341886080802e-14, 2.842170943040401e-14)
# random:
# julia> extrema( @. diff_PE + diff_WL) = (-127.08222748551799, 122.94495463691425)

Script:

import SciMLBase: step!, ODEProblem, solve, SSPRK33, savevalues!, init
using ClimaCore: Fields, Spaces
using ClimaCoupler: TestHelper
import Thermodynamics as TD
using ClimaComms
using Dates

FT = Float64
Δt_cpl = FT(200)

space = TestHelper.create_space(FT)
include("components/land/bucket_init.jl")
include("components/land/bucket_utils.jl")

test_sim = bucket_init(
    FT,
    FT.((0, 432000)),
    "sphere",
    "map_static",
    ClimaComms.SingletonCommsContext(),
    ".";
    dt = Δt_cpl,
    space = space,
    saveat = FT(3600),
    area_fraction = ones(space),
    date_ref = DateTime("19790101", dateformat"yyyymmdd"),
    t_start = FT(0),
);
test_sim.integrator.u.bucket.W .= FT(0.482052) 
test_sim.integrator.u.bucket.Ws .= FT(0)
test_sim.integrator.u.bucket.σS .= FT(-4.45e-322) 
test_sim.integrator.u.bucket.T .= FT(275.0) 

test_sim.integrator.p.bucket.P_liq .= FT(0.0) 
test_sim.integrator.p.bucket.P_snow .= FT(0.0) 
uniform = ones(space)
random = zeros(space)
parent(random) .= rand(FT, (4,4,1,96))
#evap = test_sim.integrator.p.bucket.evaporation .= random
evap = test_sim.integrator.p.bucket.evaporation .= uniform
precip = test_sim.integrator.p.bucket.P_liq .+ test_sim.integrator.p.bucket.P_snow

test_sim.integrator.p.bucket.R_n .= FT(-186.145)
test_sim.integrator.p.bucket.T_sfc .= FT(305.55)
test_sim.integrator.p.bucket.q_sfc .= FT(0.0286255)
test_sim.integrator.p.bucket.ρ_sfc .= FT(1.20363)
test_sim.integrator.p.bucket.α_sfc .= FT(0.0749572)
test_sim.integrator.p.bucket.turbulent_energy_flux .= FT(161.888)

WL_0 = deepcopy(@. test_sim.integrator.u.bucket.W + test_sim.integrator.u.bucket.Ws + test_sim.integrator.u.bucket.σS)

step!(test_sim.integrator, Δt_cpl, true)

WL = @. test_sim.integrator.u.bucket.W + test_sim.integrator.u.bucket.Ws + test_sim.integrator.u.bucket.σS
diff_WL = @. (WL - WL_0 )
diff_PE = @. (precip + evap) * Δt_cpl # bucket evap needs to be m3/m2 /s

extrema( @. diff_PE + diff_WL)

Conclusion of the DSS issue

• All models' states are DSS'd during timestepping. Their cached variables are their derivatives, so should be dss'd too, but we need to ensure all states are continuous across elements boundaries upon initialization.
• to be addressed as part of https://github.com/CliMA/ClimaCoupler.jl/issues/435

[LenkaNovak]

@kmdeck , @sriharshakandala , @simonbyrne, do you have any thoughts on whether this could be DSS?

[kmdeck]

@LenkaNovak thank you for investigating this! I'll see if I can reproduce the same type of bug in ClimaLSM using the bucket test script. I havent seen this type of behavior before, but our tests have used uniform fields. will report back :)

[kmdeck]

when is dss! applied? I think it is applied to the state after each timestep, but is it ever applied to the fluxes?

[LenkaNovak]

I don't think it is applying it to fluxes, but the fluxes are applied to the states before they're dss'd 🤔 . In the sea ice model I noticed that I had to dss cache variables (as well as the states), more specifically q_sfc, to get the correct behavior as in here.

[LenkaNovak]

This issue was closed by https://github.com/CliMA/ClimaCoupler.jl/issues/435 (but is also relevant for #484 )