Enable fwsoil_switch=Haverd2013 flag for ESM1.6

[rml599gh]

The fwsoil_switch=Haverd2013 flag does not work using the coupling code in the ESM1.5 directory. GPP become very small if the model manages to keep running.
Comparing with ACCESS-CM2 coupling where the Haverd2013 flag was enabled it looks like a few changes may be required.
Set veg%gamma=3.e-2
Initialise canopy%fwsoil = 1.

The CM2 coupling code includes quite a bit of extra code in initialize_soil in cable_um_init_subrs.F90. Lots of this is for the groundwater scheme but it appears that some of the code is needed for the Haverd2013 flag such as setting the ssat_vec and swilt_vec arrays.

[rml599gh]

Uses ssnow%wbliq as well which is not set up in ESM1.5. In CM2 this is coded to allow for different rho_water and rho_ice as used in groundwater scheme. CM2 kept it as rho_water = rho_ice.

[rml599gh]

With these code changes a one-month test now gives realistic GPP. I have done tests with the new code switching between 'standard' and 'Haverd2013' and have compared both cases with (hopefully) the equivalent run with my previous code. There is some difference between old and new code with the 'standard' fwsoil_switch.

The difference is larger when using the new code and switching between 'standard' and 'Haverd2013'

To get this running, I was writing out the different terms that go into / come out of the getrex_1d subroutine used in cbl_dryLeaf when the Haverd2013 flag is used. The 'fwsoil' value didn't appear to change in time which surprised me. I haven't worked through the code carefully yet but any thoughts @JhanSrbinovsky , @har917

[JhanSrbinovsky]

Not yet. Pleasure to look at something else. My run crashed run after 10years. Perturbed, ran again, crashed after a further ~20. Qsubbing exactly the same thing crashed in the same spot. So threre is a genuine problem. Unfortunately 22minutes into the yearly CRUN, will take days running with -fpe0 to even get that far and then might not even tell us anything. So I changed the dump frequency to every month, to narrow it down, and guess what – it is now several years in. So is there a genuine problem or not. Very annoying. I (hopefully) am running the ESM16 build through PAYU. Perhaps the consistency of compilers across the models etc can smooth this out or we are in an awkward position.

[JhanSrbinovsky]

Can you clarify please what you mean by old and new code?

[rml599gh]

'Old' in this context means my recent executables that I've been using for my 20-100 year test runs. It is up to date with 'main' from maybe a month or so ago with some local subroutines changed so that I could switch between different parameter values for refl/taul etc.
'New' has additional local edits to try and get the Haverd2013 flag working. The changes are in
/g/data/p66/rml599/ESM1.5-CABLE3-main/submodels/UM/umbase_hg3/src/atmosphere/CABLE/src/coupled/ESM1.5/CABLEfilesFromESM1.5/cable_um_init_subrs.F90 (this version also set up to hard-wired use rootbeta rather than froot)
Also compiled with extra diagnostic write statements in
/g/data/p66/rml599/ESM1.5-CABLE3-main/submodels/UM/umbase_hg3/src/atmosphere/CABLE/src/science/canopy/cbl_dryLeaf.F90

[JhanSrbinovsky]

ok thanks - by "old" I thought you might mean CMIP6-ESM1.5

[rml599gh]

Ideally I don't think we want to see any difference between the two runs using fwsoil_switch='standard', which makes me wonder whether there is anything else in the science code that uses the variables that I've added for using Haverd2013, which maybe hadn't been initialised in the ESM1.5 case.

[rml599gh]

As discussed in the CABLE4 meeting, wbliq is not changing in my test case which would explain why fwsoil isn't changing.
Looking at the code, most of the places where wbliq is used or updated is in groundwater specific code (e.g. subroutines called via soil_snow_gw), or when soil_thermal_fix is true.
If groundwater isn't being run, cbl_soilsnow_main.F90 has
REAL :: wbliq(mp,ms) at line 59 and
wbliq = ssnow%wb - ssnow%wbice at line 87 and 194.
It's not clear to me whether wbliq is ever used and, if it's just internal to this subroutine this suggests that ssnow%wbliq isn't being updated (consistent with what I'm seeing). Am I reading this correctly?

[JhanSrbinovsky]

Was @har917 there? Ian has been reading through this code recently re: the water balance issue in AM3.

[rml599gh]

Yes, Ian pointed me to checking wbliq.

[rml599gh]

Made changes in cbl_soilsnow_main.F90: deleted the local declaration of wbliq and changed the other two statements to ssnow%wbliq=...
Test runs shows wbliq now updating.
Sensitivity to changing fwsoil_switch from 'standard' to 'Haverd2013' is now. Overall, not very different from the incorrect constant-fwsoil case except in SE Australia.

I'll run a longer test now that we are a little more confident that this is doing what it should.
I did check the CABLE-2.5-ACCESS-CM2 branch and
CABLE/core/biogeophys/cable_soilsnow.F90 has
ssnow%wbliq = ssnow%wb - ssnow%wbice at lines 1783 and 1833 suggesting it was OK then.

[rml599gh]

And to save scrolling between the previous figures, this is the difference in Jan GPP between the varying wbliq and constant wbliq tests.

[JhanSrbinovsky]

could be just me but I can't get the file

[rml599gh]

Which file?

[JhanSrbinovsky]

its ok, I can see it inline now. is this a relative difference. you clearly got wbliq varying in time. Was this line not in ESM1.5? Thats very strange. If so could that explain/add to the decreased variability you saw before?

hang on you mean that wbliq line wasn't in the CABLE3 (taken from main) version. Thats very odd. It's definitely in AM3. ahhhh OK, its treated as local only

[rml599gh]

Putting the wbliq change into a separate issue as this looks like a bug that also impacts some offline cases.

[JhanSrbinovsky]

it definitely would. So have you just added ssnow% to the wbliq. Perhaps we can get this bug fix through super-quick.

[har917]

@JhanSrbinovsky @rml599gh This needs consideration within the context of the other ice-fixes that are in-train in the AM3 development. It could be a non-issue once CABLE3-MAIN is sync'd with that work (and ESM1.6 picks up the latest CABLE3)

[rml599gh]

Also noting, that my current test implementation of initialising wbliq in ESM1.5 maintains the assumption that rho_ice = rho_water, so that should be cleaned up once AM3 changes are sync'd.

I have some longer tests now with results that weren't really what I expected. Here is 12 month running mean GPP for 9 years.
We expect black/red to be similar and blue/cyan to be similar. Each pair has the same settings, just uses code that has the changes in to enable Haverd2013 but with out it switched on. Green and magenta have Haverd2013 turned on. It hasn't changed things too much in runs using 'rootbeta' (magenta compared to blue/cyan) but has decreased GPP substantially in the 'froot' case (green compared to red/black)

Also changing to Haverd2013 doesn't seem to have helped the 30-80N seasonal cycle of NEP (@juergenknauer). Colours as GPP plot.

[JhanSrbinovsky]

no doubt it will come in with AM3, I'm only worried about how long that will take. rho_ice = rho_water (from memory this is quite high up isnt it) might complicate things