'Meier 2022' z0 parameterization causes errors with FATES (especially in SP mode.)

[rosiealice]

Brief summary of bug

The implementation of the Meier 2022 paameterization for the z0param_method causes errors in FATES that are especially large in SP mode.

General bug information

CTSM version you are using: [output of git describe]
ctsm5.3.018

Does this bug cause significantly incorrect results in the model's science? Yes

Configurations affected: [Fill this in if known.]
FATES, FATES-SP

Details of bug

The Meier 2022 implementation of the z0 param method, specifically this line

CTSM/src/biogeophys/CanopyFluxesMod.F90

Line 901 in fb89f33

displa(p) = htop(p) * (1._r8 - (1._r8 - exp(-(cd1_param * lt)**0.5_r8)) / (cd1_param*lt)**0.5_r8)

overwrites the DISPLA_PATCH values, that are previously calculated as a FATES variable. These values are wrong in FATES-SP mode, because the code uses the 'HTOP_PATCH' variable to recalculate 'DISPLA' , but in FATES-SP mode, this HTOP value is the driver variable for SP mode and is not an output of FATES. Instead, we should be using HTOP_HIST_PATCH for this calculation, which contains the output from FATES assigned the the correct PFT patches.

There are also several instances where itype is used to define a patch property, which cannot be used when FATES is on.

CTSM/src/biogeophys/CanopyFluxesMod.F90

Line 906 in fb89f33

U_ustar_ini = (z0v_Cs(patch%itype(p)) + z0v_Cr(patch%itype(p)) * lt * 0.5_r8)**(-0.5_r8) &

CTSM/src/biogeophys/CanopyFluxesMod.F90

Line 903 in fb89f33

lt = min(lt,z0v_LAImax(patch%itype(p)))

This means that the displacement height in FATES-SP, for example, is way to low in the tropics.

and this seems to lead to a larger boundary layer resistance.

A solution is to use the alternative parameterization (ZengWang2007). I am not familiar with the motivation for including Meier2022 in the first place though. Should we reimplement it in FATES? @swensosc @RonnyMeier can you advise?

I currently suspect that since whenever this is was made the default it will have affected all CLM-FATES simulations, including @adrifoster's calibration runs.

Definition of done:

• Bring in changes so that ZengWang is the default for FATES, and disallow using Meier
• Make the needed changes to the code so that Meier can be used with FATES
• Do a scientific evaluation of the use of Meier with FATES
• Allow Meier to be used with FATES
• Change the default for FATES to be Meier to be consistent with clm6_0

[wwieder]

Thanks for raising this issue @rosiealice. Is displacement height handled correctly in FATES-SP with the Meier scheme off? If so, I wonder if (on the timescale of a CLM6 release) FATES cases should be set to have Meier off by default? Hopefully something we can discuss at an upcoming SE (or science) meeting.

[RonnyMeier]

Hi
I have not worked with CLM the last three years. So, I can't be of help with this question. I know for sure however that I never tested there modifications with FATES. Therefore the two might well be not compatible.

[adrifoster]

Hi all,

Yes my newest simulations were run with Meier2022. This really should not have been allowed when it was brought in as default.

[adrifoster]

@rosiealice do you think I need to re-run all of my new simulations?

[rosiealice]

But @RonnyMeier the CLM code is like Narnia. To you in the real world it might seem like three long years have passed, but in CanopyFluxesMod t'was just the blink of an eye....

In all seriousness though, I guess my question is "do we need to worry about anything very bad happening to the boundary layer parametrization if we switched back to the old scheme?" for which I think the answer likely remains unchanged today as it did in 2022.

[rosiealice]

@adrifoster I agree on all of this. One thing I think this might plausbly/hopefully fix is why we need to alter (as I undertstand it and this might be out of date) the stomatal intercept in the calibration. That might have been a thing the model was needing to do to get over the high boundary layer resistance?

[adrifoster]

Yes very true...

[rosiealice]

@glemieux was going to implement a PR to switch the default namelist settings for FATES...

[glemieux]

Working on that now. @ekluzek @wwieder I'm going to put this on the agenda to discussion at the SE meeting this Thursday. We'd like to get this in sooner rather than later.

[ekluzek]

Yes, sooner than later would be best for something that produces bad results. As part of that you should also have CTSM die if FATES and Meier are chosen.

This would also be something good to discuss as a case study of something where it seemed like it was a HLM decision independent of FATES, but caused problems in FATES. As I understand the issue here -- it's NOT that Meier couldn't in principle be used with FATES it's that there was an imbedded assumption for BGC behavior that didn't do the right thing for FATES. It will help us to look for and recognize that pattern in the code as changes come in. And the best thing would be for CTSM to operate in a way that it doesn't have to know whether FATES or BGC is being used. We did ask the question of whether Meier could be used with FATES -- but came up with the wrong conclusion.