Code update for HR4_roughness, background diffusivity and shallow convection

[Qingfu-Liu]

Description: This PR#119 is created based on the code changes from Jongil Han
The overall features for the updates are:

1. The current wave model derived momentum roughness increases with increasing 10m wind speed, which can lead to too much drag in high winds and consequent reduction of TC intensity. In order to reduce the negative hurricane intensity biases when coupled with the wave model, in the modified code the momentum roughness is limited to a constant value in high winds wind speeds larger than about 30 m/s). Also, in the modification molecular viscosity effect is included to avoid too much reduction of exchange coefficients for heat and moisture in weak winds. More detailed discussion for this issue can be found here.

2. The HR2 coupled runs with the above modified surface layer scheme have been completed for the 2020 hurricane season (July 21 - Nov. 20, 2020) by Wei Li, and the hurricane stats have been evaluated by Jiayi Peng. The impacts of this change are neutral. However, the observations indicate drag reduction in high wind speed (> about 30m/s at 10m), this change is more consistent with the observation.

3. Background diffusivity (K0) in the inversion layers near the PBL top is increased from 0.15 m^2/s to 0.4 m^2/s to reduce too much stratocumulus formation in the coastal areas of the east Pacific and east Atlantic oceans [https://www.emc.ncep.noaa.gov/gmb/jhan/vsdbw/hr2d04/: hr2d01 (K0=0.15 m^2/s); hr2d02 (K0=0.3 m^2/s); hr2d03 (K0=0.4 m^2/s; hr2d04 (K0=0.5 m^2/s)].

4. Maximum allowable TKE-dependent entrainment enhancement is reduced from 15 times to 10 times in the shallow convection scheme to avoid a potential numerical instability due to too much entrainment increase. cmxfac=10 also improve hurricane forecasts in the HAFS.

[dustinswales]

@Qingfu-Liu @yangfanglin @grantfirl @mkavulich @ligiabernardet
This is related to the topic of discussion at todays ccpp physics management meeting, so why not have a working example to spur discussion.

The problem here, and elsewhere, is that host-specific changes (e.g tunings) are being added to the physics schemes, which is not sustainable as CCPP gets adopted by more hosts. For example, what if some other host that uses the CCPP is also using the samf or satmedmf schemes (maybe NRL/Neptune?) and these parametric changes are not suitable for their application?

One solution is to add the ability to control these parameters to the host, and not inside the schemes. This isolated host-specific changes to the host side of things, while making the physics more interoperable across hosts.

Here's what that could look like for the schemes in this PR.
For each scheme, there is a new type that contains 1) the default values for all parameters and 2) a procedure to override these defaults called by the host. This type is passed from the host to the ccpp scheme(s) as an interstitial. Exercising this on the host side requires some changes.. I stopped at the GFS_typedefs, I just wanted to the "tuning knobs" to be with the host and not in the physics schemes, but a host could go further and make these knobs runtime tunable by adding them to their namelist.

[dustinswales]

These changes are fine.
However, we need to revisit "best practices" for parameter tuning in the schemes sometime soon.

[grantfirl]

@Qingfu-Liu Can you double-check that the tests listed as failing in ufs-community/ufs-weather-model#2022 in the attached log file (or the list copied into the description) are all expected?

[Qingfu-Liu]

@Qingfu-Liu Can you double-check that the tests listed as failing in ufs-community/ufs-weather-model#2022 in the attached log file (or the list copied into the description) are all expected?

@grantfirl The test fails are expected since the results are changed from the new code

[grantfirl]

@Qingfu-Liu Could you please merge Qingfu-Liu#2 so that we can combine this and #133 ?

[grantfirl]

@Qingfu-Liu Could you please merge with the latest ufs/dev so that we can have this PR ready to test?

[Qingfu-Liu]

@Qingfu-Liu Could you please merge with the latest ufs/dev so that we can have this PR ready to test?

@grantfirl I just merged PR#119 with the latest ufs/dev

[JessicaMeixner-NOAA]

@JongilHan66 I'm concerned that removal of this section of code is having some unintended effects. It's my understanding is that this code was put in by Moorthi after we noticed there were issues with where the atm model expected z0 from waves, and the vlaues that the wave model sent, whether it was land/sea masks or a value the atm model did not thinkk was acceptable. I ran a few of the regression tests offline and I saw this:

On the left is the differences and on the top right is from this branch and the bottom right is from develop. It's easy to see this issue by the differences being near land/sea masks and in lakes. Please let me know if you'd like to discuss this more offline and sorry for the delay in looking closer at this before.

[JongilHan66]

@JessicaMeixner-NOAA I thought that section would not be necessary as molecular viscosity effect is now included (which will result in z0 > 1.e-7 always). But I have no objection to recover that section for a safety.

[JessicaMeixner-NOAA]

@JongilHan66 I think focusing on for example the lakes really shows where this is needed. Otherwise it defaults to the minimum value because the waves do not provide a roughness length there.

[JongilHan66]

@Qingfu-Liu @JessicaMeixner-NOAA Hi Qingfu, could you recover that section to the original one, i.e.,

! elseif (z0rl_wav(i) <= 1.0e-7_kp .or. &
! & z0rl_wav(i) > 1.0_kp) then
!! z0 = (charnock / grav) * ustar_wat(i) * ustar_wat(i)
! tem1 = 0.11 * vis / ustar_wat(i)
! z0 = tem1 + (charnock/grav)*ustar_wat(i)*ustar_wat(i)

! if (redrag) then
! z0rl_wat(i) = 100.0_kp * max(min(z0, z0s_max),1.0e-7_kp)
! else
! z0rl_wat(i) = 100.0_kp * max(min(z0,0.1_kp), 1.0e-7_kp)
! endif
! endif

==>
elseif (z0rl_wav(i) <= 1.0e-7_kp .or. &
& z0rl_wav(i) > 1.0_kp) then
! z0 = (charnock / grav) * ustar_wat(i) * ustar_wat(i)
tem1 = 0.11 * vis / ustar_wat(i)
z0 = tem1 + (charnock/grav)*ustar_wat(i)*ustar_wat(i)

          if (redrag) then
            z0rl_wat(i) = 100.0_kp * max(min(z0, z0s_max),1.0e-7_kp)
          else
            z0rl_wat(i) = 100.0_kp * max(min(z0,0.1_kp), 1.0e-7_kp)
          endif
        endif

[Qingfu-Liu]

@JongilHan66 I have added this section of original code and tested in suite control_p8. Can you review the new code? Thanks

[JongilHan66]

@Qingfu-Liu I saw that that section was correctly recovered to the original one.

[Qingfu-Liu]

Jongil, OK. I will add the section of the code to the PR#119. Qingfu

…

On Wed, Jan 17, 2024 at 2:54 PM JongilHan66 ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In physics/SFC_Layer/UFS/sfc_diff.f <#119 (comment)> : > @@ -425,17 +437,6 @@ subroutine sfc_diff_run (im,rvrdm1,eps,epsm1,grav, & !intent(in) z0rl_wat(i) = 1.0e-4_kp endif - elseif (z0rl_wav(i) <= 1.0e-7_kp .or. & @Qingfu-Liu <https://github.com/Qingfu-Liu> @JessicaMeixner-NOAA <https://github.com/JessicaMeixner-NOAA> Hi Qingfu, could you recover that section to the original one, i.e., ! elseif (z0rl_wav(i) <= 1.0e-7_kp .or. & ! & z0rl_wav(i) > 1.0_kp) then !! z0 = (charnock / grav) * ustar_wat(i) * ustar_wat(i) ! tem1 = 0.11 * vis / ustar_wat(i) ! z0 = tem1 + (charnock/grav)*ustar_wat(i)*ustar_wat(i) ! if (redrag) then ! z0rl_wat(i) = 100.0_kp * max(min(z0, z0s_max),1.0e-7_kp) ! else ! z0rl_wat(i) = 100.0_kp * max(min(z0,0.1_kp), 1.0e-7_kp) ! endif ! endif ==> elseif (z0rl_wav(i) <= 1.0e-7_kp .or. & & z0rl_wav(i) > 1.0_kp) then ! z0 = (charnock / grav) * ustar_wat(i) * ustar_wat(i) tem1 = 0.11 * vis / ustar_wat(i) z0 = tem1 + (charnock/grav)*ustar_wat(i)*ustar_wat(i) if (redrag) then z0rl_wat(i) = 100.0_kp * max(min(z0, z0s_max),1.0e-7_kp) else z0rl_wat(i) = 100.0_kp * max(min(z0,0.1_kp), 1.0e-7_kp) endif endif — Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGTS6USGG3DYQFUYIVYEX53YPAT7HAVCNFSM6AAAAAA6CHPUHOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMRYGA3TEMJRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[grantfirl]

@Qingfu-Liu Is this ready to retest?

[JessicaMeixner-NOAA]

Has anyone ran a new test and looked at the roughness to confirm we for example get non-default values over the lakes?

[Qingfu-Liu]

@Qingfu-Liu Is this ready to retest?

@grantfirl Yes. It is ready for retest

[JessicaMeixner-NOAA]

@Qingfu-Liu @JongilHan66 have either of you run a test to confirm that we are now getting z0 calculated over lakes as in the develop branch?

[JongilHan66]

@JessicaMeixner-NOAA No. I don't know how to check z0 over lake. If you can, could you check it as you did previously?

[JessicaMeixner-NOAA]

You can check this by running the coupled model and looking at the surface output from the atmospheric model and plot z0. I will start some tests and post the results here soon. If the queue is fast, I should have something to post by the end of the afternoon.

[JessicaMeixner-NOAA]

The reinstated code is acting as expected from what I can see. Here's the same figure from #119 (comment) from the current version of the code, where we can note that the lakes are not all the blue color//1e-7 value.

[grantfirl]

@Qingfu-Liu Can you please merge in the latest ufs/dev branch so that we can sync the code for testing?

[Qingfu-Liu]

@Qingfu-Liu Can you please merge in the latest ufs/dev branch so that we can sync the code for testing?

@grantfirl OK. I just merged the latest ufs/dev branch with this PR

[zach1221]

@grantfirl testing has completed on ufs-wm PR #2022. Please merge this ccpp-physics subcomponent PR for us.