implementation of new orographic drag parameterization scheme to alleviate wind bias in E3SM

[jinboxie]

The current pull request includes incorporation of a suite of new orographic drag parameterization schemes into E3SM. It includes 4 components all combined in one module (i.e. subroutine gwdo2d). The schemes include orographic gravity wave drag (oGWD, Xie et al.,2020), flow-blocking drag (FBD, Xie et al.,2020), small-scale GWD (sGWD, Tsiringakis et al.,2017), and turbulent-scale orographic form drag (TOFD, Beljaars et al., 2004).
The scheme are distributed by the interface named gwdo_gsd.
The oGWD, FBD, and sGWD are implemented in gw_drag.F90, while TOFD is implemented in clubb_intr.F90 to join the vertical diffusion process. Another change is in the startup_initialconds.F90/gw_drag.F90 where the new topographic parameters (OA, OC, OL) are input into the model.

---

(formation of the additional topographic parameters are documented here).
The results tested in E3SMv2/v3 documented here. The overall 5-yr F2010 results between CTL run (default E3SMv3) and 3GWD-3FBD-sGWD-TOFD run (experimental run using new schemes) show that the new schemes help to alleviate the 10-m wind speed bias compared to ERA5 in E3SMv3.

---

The namelist control is added for the 4 schemes. The 4 schemes are separately control by namelist variables
use_od_ls (oGWD)
use_od_bl (FBD)
use_od_ss (sGWD)
use_od_fd (TOFD)
tunable parameters in the schemes are also controllable via namelist, e.g.
ncleff_ls (oGWD)
ncd_bl (FBD)
sncleff_ss (sGWD).

---

The code has passed all the tests in the "e3sm_atm_developer" suites.

---

---

Figure 1 5-yr F2010 simulation for E3SMv3 (0001-0005) vs ERA5 climatology (1979-2019) for 10-m wind speed (a-b) and 2-m temperature (c-d).

[github-actions]

PR Preview Action v1.4.8
🚀 Deployed preview to https://E3SM-Project.github.io/E3SM/pr-preview/pr-6667/
on branch gh-pages at 2024-10-22 07:08 UTC

[oksanaguba]

A few questions, please -- are these drags energy conserving? I assume at least the one in clubb is not (from reading the code)? Should we run some checks to confirm this?

Separately, if these are topo drag parameterizations, why does this PR introduce changes in the topo tool? In other words, how/why are these parameterizations affecting topo generation?

Were these parameterizations tuned to show smaller bias? I assume only one was used to report smaller biases as above, what about the other 3? (unless they all run together?) UPDATE -- it seems they ran together.

If i knew that this code base (physpkg.F90, etc) is to be used for a while, i would suggest for you to remove the code from clubb_intr and make is a separate module/routine. You can then use that new code to add another forcing term to cam_in structure to be "absorbed/diffused" by clubb. This is to separate clubb interface code from clearly a different parameterization.

thanks!

[jinboxie]

A few questions, please -- are these drags energy conserving? I assume at least the one in clubb is not (from reading the code)? Should we run some checks to confirm this?

Separately, if these are topo drag parameterizations, why does this PR introduce changes in the topo tool? In other words, how/why are these parameterizations affecting topo generation?

Were these parameterizations tuned to show smaller bias? I assume only one was used to report smaller biases as above, what about the other 3? (unless they all run together?) UPDATE -- it seems they ran together.

If i knew that this code base (physpkg.F90, etc) is to be used for a while, i would suggest for you to remove the code from clubb_intr and make is a separate module/routine. You can then use that new code to add another forcing term to cam_in structure to be "absorbed/diffused" by clubb. This is to separate clubb interface code from clearly a different parameterization.

thanks!

Hi Oksana @oksanaguba ,
Thank you for the questions!
In terms of the energy conserving, I'm not sure I understand this correctly. Did you mean the fixer that gw energy fixer that was implemented in gw_drag.F90? I'm not familiar with this part, could you maybe clarify on how to test it?

The introduction of changes in topo tool (creation of a separate folder for generation of additional topographic parameter) does not affect the current topo generation. It is used to generate additional topographic parameters (such as orographic asymmetry, effective orographic length) that are needed for the new OGWD parameterization. The process is documented here.

For implementation of turbulent orographic form drag (TOFD, the turbulent mountain stress (TMS) equivalent) into the CLUBB intr. I was following the previous implementation of TMS. What we input into the clubb_intr is an interface that utilizes the module of the new schemes (with only TOFD opened, others closed here. The other 3 schemes are opened in gw_drag.F90).
(Note that the 4 schemes are modulized, and easily distributed through opening and closing flags with an interface).

Unlike TMS, the TOFD can generate a profile rather than a single-level surface stress. We had to find a way to input this forcing profile of TOFD into the clubb to join the vertical diffusion (or maybe what you meant by "absorbed" by clubb?).
So we are currently following TMS's positioning in clubb_intr, the minor difference is that TMS is inputting surface wind forcing (upwp_sfc, vpwp_sfc) while we are inputting wind profile forcing terms (um_forcing, vm_forcing) into clubb at the clubb_intr.

So in this code, I was inputting an interface for the calculation of the TOFD into clubb_intr while the module is somewhere else in physics folder. I was wondering if you'd meant to put this interface of the new scheme out in physpkg.F90 instead?
Thanks!

Jinbo

[jinboxie]

@mt5555
Hi Mark,
I have a question in terms of the topography file. The current implemented scheme involves use of additional topographic parameters that are added in the topo file, (generation method documented here). Take ne30pg2 as an example (USGS-gtopo30_ne30np4pg2_x6t-SGH_forOroDrag.c20241001.nc in replacement of USGS-gtopo30_ne30np4pg2_x6t-SGH.c20210614.nc), the original variables such as PHIS, SGH, SGH30 are the same, except for addition of parameters such as orographic asymmetry (OA), orographic convexity (OC), etc. These are needed when new scheme is open while not needed when the default GWD is used.
I was wondering if I can update the file in the namelist like this (replacing the default used topo file, the new topo data is on chrysalis input directory and shared over other servers), or would you suggest alternative options?
Jinbo