lake tiles in offline appear broken

[har917]

Conceptually the lake tile in CABLE is modelled as a permanently saturated bare soil surface. In the coupled model this is achieved in two steps:

• at the beginning of each time step (explicit section) the soil is set to saturation. any increment of water necessary to achieve this is diagnosed into %wb_lake (see um_update_soilsnow)
• in soilsnow/surfbv the increment %wb_lake is used to extract water from runoff, drainage and from the deepest soil layer in an attempt to balance water within the time step. Any residual imbalance is retained and then used as a scaling on river outflow (in fully-coupled model).

In offline we have retained the section in surfbv but do not have an obvious equivalent section to the resetting of soil moisture to saturation and evaluation of %wb_lake. Since %wb_lake is initialised to zero the whole code becomes effectively inactive. The net result is that lake tile behaves like a bare soil tile with notable variations in soil moisture (as seen in recent analysis of the offline-as-ACCESS configuration)

Also: follow up on what is supposed to happen with wetlands - are these supposed to be saturated grasslands?

[har917]

After a bit of detective work we likely need to add a short section to offline cable_cbm.

Specifically most (if not all) of cbl_um_update_soilsnow needs to be added prior to the call to define_canopy.

For longer-term safety (in case we ever activate a soil moisture dependence to soil_colour and soil albedo) this would be better located at the start of the cbm routine (alongside a move of lines 166, 167 and 171), i.e. before the call to the albedo() code.

[har917]

@ccarouge Do we have a lake tile in the standard benchcab suite? Just thinking about how to test this.

[har917]

We should also take the opportunity to remove the hard-wired lake (=16) index from the CABLE code base and replace with USE grid_constants_mod_cbl, ONLY : lakes_cable

[JhanSrbinovsky]

I'm a bit confused - is this to make it consistent to AM3?

[har917]

I'm a bit confused - is this to make it consistent to AM3?

This came about from analysis by @rml599gh looking at conditions over a lake region in offline-as-ACCESS - offline is/was producing noticeably different behaviour in screen temperature which was tracked down to differences in soil moisture. It appears that the coupled model (in the interface routines) ensures that lakes soil moisture doesn't drop below a limit (with a compensatory adjustment to runoff and - in CM2 - river flow) but that this has been dropped/never applied to offline.

This issue is about coming to a consensus around what should be happening - in the first instance applying the same/similar treatment for soil moisture in offline.

There is a little bit of residual difference in approach as of 16/7/2024 - in that #348 the implementation basis soil moisture for lakes around saturation (%ssat) whereas ESM/CM2 use field capacity %sfc - we should work towards a consistent use across ESM1.6, AM3/CM3/ESM3 and offline.

@ccarouge @JhanSrbinovsky - from software engineering principals should we apply this with a %sfc limit (and then assess the impact of going to %ssat) or are we happy to go to %ssat directly [and presumably port that change to ESM1.6 and AM3 later as a new issue.]

[har917]

Spotted two further hard-wired lakes in gw_hydro subroutines iterative_wtd and sub_aquifer - note that these assume tile ordering (and will be added to the list in #347)

[JhanSrbinovsky]

IDK that there would be a guiding principle. Considering my only experience of this was that back in the day it was explained to me that CABLE doesnt really have lakes and we force saturated bare soil via the parameters - it sounds to me like a bug in offline that it was allowed to be sfc. I'd be happy to just correct it. Other than "changing" results, has it negatively impacted anything by ensuring consistency and adopting sfc?