Surface roughness modifications

[RonnyMeier]

This branch contains the surface roughness (z0) modifications published in: https://doi.org/10.5194/gmd-15-2365-2022

When changing the namelist input z0param_method from ZengWang2007 (default) to Meier2022 the following modifications are activated:

• A new parameterization of the vegetation surface roughness based on Raupach (1992) with optimized parameters to match the data collected in Hu et al. (2020) for different types of vegetation. This requires several new PFT-specific input parameters in the parameter file.
• A spatially explicit z0m input field for bare soil based on the data of Prigent et al. (2005). This may be activated specifically by the user through the namelist input use_z0mg_2d. This requires a new input variable in the surfdata file.
• The parameterization of z0m for snow based on accumulated snow melt as proposed in Brock et al. (2006). This may be activated specifically by the user through the namelist input use_z0m_snowmelt.
• The parameterization of Yang et al. (2008) for z0h and z0q over bare soil, snow, and glaciers.

Note that the study in GMD also proposes new globally constant values for the z0m of bare soil, snow, and ice. To "activate" those the parameter file needs to be changed at the moment. The original and modified parameter files and surfdata files will be shared by ftp.

Open issues/questions (already discussed with @ekluzek, @dlawrenncar, and @olyson:

• How to incorporate the data of Prigent et al. (2005) in the surfdata generation. I will write an email about this to Catherine Prigent.
• One statement marked in CanopyFluxesMod should probably be changed when using Meier2022 (i.e., Yang et al. (2008) formulation should be used instead of Zeng and Dickinson (1998)).
• At the moment one needs to change the parameter file to switch between the original and proposed globally constant z0m values for bare soil, snow, and ice. This is obviously not very user friendly and prone for mistakes.
• The introduction of Yang et al. (2008) frequently results in z0h and z0q larger than z0m. This is only rarely observed in the field and in contradiction to the theory that z0h and z0q should be smaller because heat and water vapor need to be transported through molecular diffusion in the surface sublayer.

Issues Resolved: #1316

[ekluzek]

I know the date for your paper isn't completely known right now (hence the XXXX in the namelist name). But, it seems like we'll want a real year when this comes into main-dev of CTSM. So I propose we go with Meir2022? I think in the context of namelist options for CTSM being off a bit in the namelist name is acceptable. Especially if the exact reference is pointed to in the code. And we should put the reference in appropriate places where it's refereed to.

[ekluzek]

@RonnyMeier thanks so much for your work on this. This looks really good to me overall. I like the namelist control you added in, as well as the use of case statements for choices. You did a great job with the build-namelist work as well.

One thing that would help with this is that this currently includes changes outside of surface roughness. It also includes running PFT's on their own column, which is in a different PR to come in (#1249), and local time history averaging which already came in PR #1374. It would help to see this without both of those.

It'll likely help prevent conflicts in merging forward, if the local time history changes are removed from here. The update to a newer version will automatically bring it back in anyway.

I also think it's good to have the PFT on a column as a separate PR as well. I remember discussing that one and I don't remember what our conclusion was on including it. I'll make a point of having the software group discuss it more again next week. So removing that would allow us to bring it in separately.

I have some detailed questions that I've put in the code as well. Mainly there is some commented out code that looks like it's for a different option. If you had time to develop it into a third option I think that would be the best path forward. But, because we only have a week, I think the best would be to just remove the commented out code.

I also noticed repeated hardcoded constants. Some of these existed before your work in the code, so aren't really your fault, but still would be good to change into parameters. If they are used only in one file, making them local parameters would be fine. If they are used in more than one file adding them to clm_varcon might be better. If they are something that someone might want to tune, they could be put on the paramsfile. Just elevating them to a local parameter helps though in any case.

Separately I also suggest that MeirXXXX become Meir2022, but we can discuss that. And feel free to discuss any of this, there's always room for talking this over.

But, good work here. Thanks for your contribution. Best of luck on your future endeavors, outside of academia.

[ekluzek]

7.5_r8 should be made into a parameter that helps describe what it is. Possibly the same for other variables here as well: 0.00001_r8, some of the 2's and 4's?

[ekluzek]

This still should happen.

[RonnyMeier]

Thanks @ekluzek for reviewing the code. I don't have any strong opinions regarding the tag. Meier2022 should most likely be appropriate. We can also go for MeierDavin2022 or GMD2022. Not sure if CESM has any guidlines on how to choose such tags.

The commented-out code sections marked with "! --> Use this for CLM-YY" were used for the sensitivity tests that are presented in the appendix of the GMD study. Those can all be removed (sorry I forgot to do this). What could be considered to be included as an additional option is the formulation of Owen and Thomson (1963) to compute z0hg and z0qg.

Also, I realized that we actually opened an issue for this development a couple of months ago: New parameterization of vegetation surface roughness for forests #1316

[ekluzek]

We talked about this a bit this morning.

One aspect that we should keep in mind about this is how this interacts with FATES. Our testing ensures we won't break FATES with it. Two questions are can part of it be turned with FATES, and secondly can/should FATES be updated to bring these kind of changes to the FATES side of things? Before we do that I'd like to make a little more progress so the code is a little more clearer for a FATES scientist to evaluate.

Specifically, the next steps for this are:

• Fix the subscript overflow in DEBUG mode
• Change the MeierXXXX namelist tag to Meier2022
• Tag that as a branch tag
• Remove the Local time changes
• Remove the PFT on separate columns option
• Update to the latest model version
• Make sure all model configurations work with the new option (or disable using them together)
• Run more extensive testing to make sure we agree this is good to come in
• We may remove the 2D option that requires changes to surface datasets
• Some of the parameters should be made into parameters or placed on the paramsfile
• Possibly have it turned on by default for clm5_1 physics

[wwieder]

I agree @dlawrenncar this quickly gets into questions about preferred configurations for the model moving forward. Looking more carefully at the transition to CRUJRA-TRENDY seems like a good idea

[olyson]

Per the CLM business meeting on 06/09/22, we decided to use zetamaxstable=2 for all surfaces, and further investigate setting the forcing height to 10m along with implementing CRUJRA as our default dataset but as a separate issue.
I've made a change to the CLMBuildNamelist.pm so that the proper zetamaxstable is chosen based on z0param_method.
I've also fixed a problem with setting zeta to a global variable in UrbanFluxesMod.F90.
I ran the clm_short test suite to compare with ctsm5.1.dev077 with z0param_method='ZengWang2007' and result are bfb.
So I think this is finally ready for review and full testing, although I'm not sure if all of the items on Erik's original list have been completed:

Fix the subscript overflow in DEBUG mode
Change the MeierXXXX namelist tag to Meier2022
Tag that as a branch tag
Remove the Local time changes
Remove the PFT on separate columns option
Update to the latest model version
Make sure all model configurations work with the new option (or disable using them together)
Run more extensive testing to make sure we agree this is good to come in
We may remove the 2D option that requires changes to surface datasets
Some of the parameters should be made into parameters or placed on the paramsfile
Possibly have it turned on by default for clm5_1 physics

[ekluzek]

@dmleung made a summary of the differences between the 2005 and the 2012 Prigent datasets that I'm uploading here:

Summary of Prigent's two roughness datasets (1).docx

[ekluzek]

In @dleung work #1712 has the Prigent data as drag partition factor which relates to the Meir data as follows:

f_eff.r = 1 - ( log(z0a/100/z0s) / log(0.7*(10/z0s)^0.8) )
z0s = 130e-6 / 15    # m, smooth roughness length, White (2006) equation

We should compare the two datasets to make sure they are reasonably similar. We think they will be different because the @dmlenung data is the minimum.

[ekluzek]

The thinking now is that for the 2D data here, we'll use the data from Leung 2022 (see #1712) and convert it back to what's needed here. So we won't use the Meier data that was processed partially because it's only over non-vegetated areas. We also think the choice of Leung to use the minimum makes sense physically.

[slevis-lmwg]

TODOs

1. Update to latest tag
   z0param_method can be ZengWang2007 or Meier2022
   zetamax_stable = 2 regardless of method but will depend on physics (clm45=2, clm5=0.5, clm51=2)
   use_z0mg_2d should be removed from /testmods
2. Test-suites:
   cheyenne IN PROG
   izumi
3. Refactor some of the "magic numbers" with parameter names from the corresponding publication

[slevis-lmwg]

@RonnyMeier @ekluzek
I'm ready to push the update to ctsm5.1.dev129 and need permission to do so to this PR.

@RonnyMeier can you make me a collaborator on your fork of CTSM? On your fork go to the "Settings" tab and then "Collaborators" and you should see a way to add a collaborator where you can invite @slevis-lmwg and give me permission to work on your fork.

[ekluzek]

@slevis-lmwg we haven't been able to get ahold of Ronny, so we can't push to his forks. What you'll have to do is to branch from his branch and create a branch on your own fork that will include this one.

We'll want to keep both PR's open for at least a little while to make sure everything is transferred over. And this PR will autoclose when the new branch brings it to main-dev. so it's actually OK to leave it open until then.

[slevis-lmwg]

Superseded by #2045