'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.

[adrifoster]

Hi all,

Yes I agree we should have a post-mortem on this. In a perfect world, given our original assumption that FATES should not have been affected by the Meier scheme, anything not b4b for our FATES tests should have raised an issue.

I realize that when we expect answers to change it is difficult to comb through all the tests to confirm answers changes are AS EXPECTED.

[glemieux]

Question: should PR #2934 close this issue? My assumption is "no" since theoretically we want to be able to eventually have fates run with Meier2022, correct?

[ekluzek]

@adrifoster yes a sticky problem in principle that we have is when answers are expected to change it's hard to catch problems with the answer changes. I'm excited to talk about this case though, because it's easier to talk about a specific case while it's hard to talk about the general problem. I think we can review our process and come up with some ideas to help in the future (and @rgknox already did with #2933.

A subtle problem that @rosiealice shows here is where for FATES a different variable should be used for htop and DISPLA shouldn't be changed. It would be good for the CTSM abstraction on top of FATES to be such that developers don't have to know these type of details and differences with FATES or for different BGC modes for that matter. That might be a large lift right now, but maybe we could do something like have the CTSM-FATES interface check that CTSM hasn't changed something that FATES expects to be readonly. For using the right variable we should perhaps for example set htop to nan for FATES so that it's use would trigger an error in DEBUG mode. We might be able to identify other variables that we should do that as well.

I'm suggesting that we do an extended discussion on this on Thursday. We'll probably also talk about it some in the FATES update. But, I think spending a half hour to think this through would be really good to do. I'll start some notes for doing that sort of thing. Everyone let me know what you think about that idea.

[ekluzek]

@glemieux I agree, I think we eventually want FATES to work with Meier, so the first step is to just disallow it, but later get it working correctly. And perhaps we need to do a more careful scientific evaluation this time? I'll add some notes to definition of done at the top.

[adrifoster]

@adrifoster yes a sticky problem in principle that we have is when answers are expected to change it's hard to catch problems with the answer changes. I'm excited to talk about this case though, because it's easier to talk about a specific case while it's hard to talk about the general problem. I think we can review our process and come up with some ideas to help in the future (and @rgknox already did with #2933.

Agree I think this is occurred due to a combination of some technical debt combined with inadequate testing tools. Will be good to discuss...

[ckoven]

@glemieux @ekluzek My reading of the Meier et al 2022 paper is that a FATES implementation of the concepts in there would end up being different enough as to be its own thing. So I am not sure that that we would want FATES and Meier 2022 to be compatible, even if we used some of the ideas and datasets therein in some future FATES surface roughness parameterization. I sort of remember discussions at the time and I thought that was the conclusion we made then as well. But obviously I may misremember.

[adrifoster]

@glemieux @ekluzek My reading of the Meier et al 2022 paper is that a FATES implementation of the concepts in there would end up being different enough as to be its own thing. So I am not sure that that we would want FATES and Meier 2022 to be compatible, even if we used some of the ideas and datasets therein in some future FATES surface roughness parameterization. I sort of remember discussions at the time and I thought that was the conclusion we made then as well. But obviously I may misremember.

agree @ckoven I think it would require its own calibration and parameter tuning.