wetfac calculation: ensure consistent approach for the introduction of groundwater work

[ccarouge]

The groundwater and Or evaporation schemes calculate wetfac differently to the default case. For this, the groundwater work introduces a calc_srf_wet_fraction() subroutine in cable_gw_hydro.F90.

Recently, in the main branch, some work was done on wetfac and the calculation was moved to the initialize_wetfac procedure in cbl_init_wetfac_mod.F90.

We need to decide on the approach we want to take so we do not introduce 2 equivalent subroutines in CABLE.

1. The calculations in both branches for the default case are the same except the GW work introduces the ice/liquid density ratio:

ssnow%wbice(i,1) * den_rat & ! MMY not sure whether needed but add * den_rat
                                / ssnow%wb(i,1) )**2 

but with an "unsure" comment. Do we want to adopt or not?
This corresponds to this code in main (without the densities ratio):

CABLE/src/science/canopy/cbl_init_wetfac_mod.F90

Lines 83 to 88 in 630e2e1

	ice_ratio = (ssnow_wbice(i) / ssnow_wb(i))**2
	!~ 1-Ice_ratio^2
	ice_factor = 1._r_2 - MIN(0.2_r_2, ice_ratio)
	ice_factor = REAL(MAX(0.5_r_2, ice_factor))
	ssnow_wetfac(i) = ssnow_wetfac(i) * ice_factor

2. Placement of the subroutine. I don't think placing this subroutine in the GW alternative soil module makes sense. I would keep the separate module we have introduced in main.

3. Name of file/module/subroutine. The subroutine and module in main are called initialize or init but this calculation seems to be done every time step, so not an initialisation but a calculation. Should we adopt the GW naming instead: calc_srf_wet_fraction?

This impacts the CABLE code, ESM1.6 and AM3. Any change should be introduced in all 3 code bases and tested in all 3 codes.

@har917 Any view on the use of the densities and naming?
@JhanSrbinovsky Any view on the naming? Not asking you to do anything, I just want a decision for now. If we decide on changes, ACCESS-NRI can handle them.

[har917]

So the term initialize_wetfac was introduced to isolate the main diagnostic calculation from how it eventually got used (as 0.5*(wetfac+owetfac) ) - I agree that that is a bit confusing vs how we're using initialize elsewhere in the codebase.

See my comment in #558 about different interpretation of variables - in this case is ice_ratio meant to be a volumetric fraction or a mass fraction? My guess is that it's supposed to be a volumetric (or actually area) fraction as it's the surface area exposed to water (evaporation) vs ice (sublimation) that controls the relative efficiency and that varies with the volumetric fraction.

[har917]

AM3 #273 is touching on this same part of the codebase.

Also #162, #505 and #556 touch on this indirectly since the part of cbl_SurfaceWetness is actually doing some of the time stepping of %cansto

In an ideal world we would be able to modify the code to avoid the need for %owetfac in the coupled models, and rationalize the time stepping of %cansto at the same time.

[JhanSrbinovsky]

I agree initialize is not particularly appropriate. # 273 in AM3 is just going to shove wetfac into the restart (for the sake of reproducability) so every time step it will just update from wetfac from the previous timestep OR at dt=0 it will initialize from this and not call initialize wetfac at all (which is how it captured the initialize part of the name.) So the name will be even more wrong as it is never used. Feel free to change it tot eval_wetfac, a FUNCTION or whatever. I'm not too fussed. :)