Cloud cover parameter changes for GFSv17

[RuiyuSun]

Description of Changes:

There is a low cloud bias in the current version of the GFSv17. The formula used in the cloud cover calculation is based Xu/Randall (1996). To increase the cloud cover in the GFSv17, a different set of parameters is used in the formulation. The increase in the cloud cover will also help to reduce the downward SW at the surface.

Tests Conducted:

The change has been tested in a GFSv16 RETRO-like experiment. The UFS RT tests are being conducted. The test results are here.

Dependencies:

Add any links to parent PRs (e.g. SCM and/or UFS PRs) or submodules (e.g. rte-rrtmgp). For example:

• NOAA-EMC/fv3atm#<1027>
• ufs-community/ufs-weather-model/#<2940>

Documentation:

This PR does not add new capabilities that need to be documented or require modifications to the existing documentation.

Issue (optional):

This PR is resolving #324

Contributors (optional):

@JongilHan66 @yangfanglin

[grantfirl]

Consider removing the commented-out line unless this change is temporary.

[climbfuji]

@matusmartini FYI

[RuiyuSun]

Consider removing the commented-out line unless this change is temporary.

The line is removed.

[jkbk2004]

All tests were done at ufs-community/ufs-weather-model#2948. @grantfirl @rhaesung can you merge this pr?

[grantfirl]

@RuiyuSun I noticed that one of the changes in this PR is going from using an exponent (**0.49) to sqrt(sqrt()). I'm assuming that this was done because the intrinsic sqrt function may be faster? Would you have a problem with me returning this calculation to an exponent, but making the exponent a variable? The reason that I ask if that this tuning may not be wanted/needed by all hosts (particularly NRL that requested that this change be configurable), so by making the exponent a variable, the host can control the behavior. Please let me know your thoughts.

[dustinswales]

Ugh... Having the cloud-to-radiation for two radiation schemes is once again leading to inconsistencies.
RRTMG uses a few different flavors of Xu-Randall, whereas RRTMGP uses a single (parameterized) Xu-Randall with different arguments.

@RuiyuSun For RRTMGP, when using Thompson MP we are already using alpha(xrc3)=2000 , but alpha is then further conditioned on the convection scheme being used. I think we need to redo to logic in RRTMGP to be as in RRTMG.

Also. Ditto to @grantfirl's question on the change to using the fortran intrinsics vs. exponent? (The 1996 formulation has lambda (0.50) as an exponent, no double roots). The 1996 formulation is identical to what used for RRTMGP, but not RRTMG?

[grantfirl]

@dustinswales See NCAR#1171 for generalization that Dom requested. We may need to extend for RRTMGP.

[dustinswales]

@dustinswales See NCAR#1171 for generalization that Dom requested. We may need to extend for RRTMGP.

@grantfirl Looks good. We just need to extend GFS_rrtmgp_cloud_mp.F90 to use the two coeffs from the model, instead of hardcoding them based on MP choice (This will need to be on the host side).

[RuiyuSun]

@RuiyuSun I noticed that one of the changes in this PR is going from using an exponent (**0.49) to sqrt(sqrt()). I'm assuming that this was done because the intrinsic sqrt function may be faster? Would you have a problem with me returning this calculation to an exponent, but making the exponent a variable? The reason that I ask if that this tuning may not be wanted/needed by all hosts (particularly NRL that requested that this change be configurable), so by making the exponent a variable, the host can control the behavior. Please let me know your thoughts.

@grantfirl I agree with you!

[RuiyuSun]

Ugh... Having the cloud-to-radiation for two radiation schemes is once again leading to inconsistencies. RRTMG uses a few different flavors of Xu-Randall, whereas RRTMGP uses a single (parameterized) Xu-Randall with different arguments.

@RuiyuSun For RRTMGP, when using Thompson MP we are already using alpha(xrc3)=2000 , but alpha is then further conditioned on the convection scheme being used. I think we need to redo to logic in RRTMGP to be as in RRTMG.

@dustinswales It will be fine with me.