CTSM
CTSM copied to clipboard
Make zetamaxstable consistently 2.0 when BHS on
Description of changes
Set zetamaxstable to 2.0 when BHS is on for all subgrid types. This also means to remove the hardcoded setting to 100 for vegetation when BHS is on and use zetamaxstable from the namelist.
Specific notes
Contributors other than yourself, if any: @olyson
CTSM Issues Fixed (include github issue #): Fixes #1690 Fixes #1689
Are answers expected to change (and if so in what way)? Yes
Any User Interface Changes (namelist or namelist defaults changes)? No
Testing performed, if any: namelist testing, will do regular testing
@olyson can you look this over and make sure this is correct? This uses zetamaxstable from the namelist for Canopy fluxes, so that the same value is consistent for all subgrid types: lake, bareground, veg, and urban. It also sets zetamaxstable to 2.0 whenever BHS is turned on. So this means zetamaxstable will be 2.0 for ctsm5_1 cases.
This is already done on Ronny Meier's branch and in such a way as to maintain bfb when z0param_method is not Meier2022:
https://github.com/RonnyMeier/ctsm/commits/main
Is there a reason to do this separately?
I wanted to bring in the answer changing parts in a small tag, so that the surface roughness tag could be non answer changing.
There is another answer-changing aspect of the branch that updates the forcing heights when roughness/displacement height is updated. This wasn't being done consistently before. Although I guess you could do that as another answer-changing tag.
@olyson and I chatted about this a bit so that we understood what each other was doing. He suggested that I ask @wwieder to decide how to move forward with this. I then chatted with @wwieder and we brought in @swensosc and we agreed on going this way so that a consistent zetamaxstable of 2.0 is used when BHS is on for all surface types. @swensosc didn't see a scientific reason to preserve the current behavior of having a different zetamaxstable value over vegetated land types. 100 was actually used in BHS just as a way to say "there is no cap", it was kind of a way of setting it to infinity.
Having a consistent value for all land surfaces makes the code easier to understand, from both a software and scientific perspective.
I ran some of the longer aux_test suite tests and found that two gave the same answers with only one diverging. Since, the change is to a max value you have to reach that value before answers will change.
This test showed answers that diverge: SMS_Lm13_PS.f19_g17.I2000Clm51BgcCrop.cheyenne_intel.clm-cropMonthOutput
And these tests were identical: SMS_Lm37.f10_f10_mg37.I1850Clm50SpG.cheyenne_intel.clm-glcMEC_long SMS_Ly1_Mmpi-serial.1x1_brazil.IHistClm50BgcQianRs.cheyenne_intel.clm-output_bgc_highfreq