remove Zhao-Carr cloud schemes and combine Xu-Randall cloud fraction calculation

[Qingfu-Liu]

Description of Changes:

1. Remove Zhao-Carr cloud schemes which are no longer used in the CCPP physics suites. The new code changes remove cloud calculation for "progcld_zhao_carr" and "progcld_zhao_carr_pdf".
2. Create a new function cld_frac_XuRandall in the module_radiation_clouds, and replaced the subroutines "cloud_fraction_mass_flx_2", "cloud_fraction_mass_flx_1", and "cloud_fraction_XuRandall" with the new function.
3. remove the function cld_frac_XuRandall from program GFS_rrtmgp_cloud_mp.F90, and replaced the function with the new functionly created function cld_frac_XuRandall in the module_radiation_clouds.

Tests Conducted:

Regression tests are conducted on Ursa, and the results are binary identical

Dependencies:

No dependence

Documentation:

No new document (not needed)

Issue (optional):

No issues. The changes remove Zhao-Carr cloud schemes which are no longer used, and combine some similar subroutines

[dustinswales]

@Qingfu-Liu Thanks for making these changes.

1. I love to see radiation_clouds.f getting some long overdue housekeeping. Good work!
2. It's great that the RRTMG-CLDMP coupling now has only one (configurable) flavor of Xu-Randall, but it appears that we now have two identical Xu-Randall cloud fraction routines; The one being introduced here in radiation_clouds.f for the RRTMG cloud coupling, and one used for the RRTGMP cloud coupling, GFS_rrtmgp_cloud_mp.F90.

Could we create a new module, say physics/Radiation/radiation_cloud_fraction.F90, which contains a single Xu-Randall cloud fraction routine that both RRTMG (physics/Radiation/radiation_clouds.f) and RRTMGP (physics/Interstitials/UFS_SCM_NEPTUNE/GFS_rrtmgp_cloud_mp.F90) uses?

[Qingfu-Liu]

@dustinswales OK. I will make the changes. Thanks.

[Qingfu-Liu]

@dustinswales I cross-checked the code between cld_frac_XuRandall (RRTMGP) and cloud_fraction_XuRandall (RRTMG), there is small differences between the two:
Line 806 (/scratch3/NCEPDEV/global/Qingfu.Liu/git/ufs-weather-model_20251229/UFSATM/ccpp/physics/physics/Interstitials/UFS_SCM_NEPTUNE/GFS_rrtmgp_cloud_mp.F90)
tem2 = max(min(tem1*(cld_mr - clwt), 50.0 ), 0.0 ) (where clwt = 1.0e-6 * (plyr(i,k)0.001))
Line 3160 (/scratch3/NCEPDEV/global/Qingfu.Liu/git/ufs-weather-model_20260105/UFSATM/ccpp/physics/physics/Radiation/radiation_clouds.f_save)
value = max( min( tem1(clwf(i,k)-clwm), 50.0 ), 0.0 ) (where clwm=0. here)
Do you have any comments/suggestions (I prefer to use the RRTMG version here since no impact on the GFSv17 regression tests)

[dustinswales]

@Qingfu-Liu I don't understand the need for this line? (clwmin =0 above)

[Qingfu-Liu]

Yes. we can remove this line here. Should we change the line 806 in GFS_rrtmgp_cloud_mp.F90 as:
tem2 = max(min(tem1*(cld_mr-clwm), 50.0 ), 0.0 ), where clwm=0. in RRTMG
My guess is that clwm=clwt when you change the code for RRTMGP

[dustinswales]

@Qingfu-Liu If clwm = 0, then why subtract it from here.

[dustinswales]

@Qingfu-Liu I don't want to make the call here, but I "think" the GP formulation is correct, and the G formulation is not. At least when looking back at https://journals.ametsoc.org/view/journals/atsc/53/21/1520-0469_1996_053_3084_ascpfu_2_0_co_2.xml?tab_body=pdf.
We should select one, and whichever way we choose, it will impact the other radiation scheme. Thoughts?

[Qingfu-Liu]

@dustinswales I will do some more research. From the code, the two cloud fraction calculations for RRTMG and RRTMGP are different.

[dustinswales]

@Qingfu-Liu As you pointed out, the algorithms are nearly the same, with small differences in the exponent.
For RRTMG, exponent = cloud mixing ratio - clwm (set = 0)
For RRTMGP, exponent = cloud mixing ratio - minimum allowable condensate (~1e-8)

So whatever way is "correct", it will impact the other and cause answer changes. But they should be the same.

[Qingfu-Liu]

@dustinswales I have modified the RRTMG code to make the Xu-Randall subroutine elemental and can be used for RRTMGP ( slightly modify the input variables). I will upload the code after the regression tests

[Qingfu-Liu]

@dustinswales I uploaded the new code and change the RRTMG Xu-Randall subroutine to be a function and elemental, and can be called in the RRTMGP scheme with extra input control variable "factor".

[dustinswales]

@Qingfu-Liu Thanks for doing this.
For GP (GFS_rrtmgp_cloud_mp.F90) we will need to:

• Import cld_frac_XuRandall from module_radiation_clouds here
• Remove the cld_frac_XuRandall subroutine from here
• Modify calls to cld_frac_XuRandall in GFS_rrtmgp_cloud_mp to provide "factor=1".

Ultimately, I think FactorG=FactorGP, but this will not give us B4B reproducibility for the RRTMGP test if we adopt this here.
Even though the change is probably insignificant, I'm reluctant to support this w/o some testing in a GP enabled application.

[Qingfu-Liu]

@dustinswales I have removed the cld_frac_XuRandall function from RRTMGP scheme, and replaced the function from module_radiation_clouds. The regression tests from RRTMGP (two suites in the default rt.conf) produce binary identical results.
I am going to run the regression test for all the suites in the default rt.conf.

[dustinswales]

Why do we need to declare this local pressure var?
Can't you just pass p_lay(iCol,iLay) *0.01 into cld_frac_XuRandall?

[Qingfu-Liu]

we can change this

[dustinswales]

Isn't lambda a constant for the cld_frac_XuRandall()?
Can we move is back in there?

[Qingfu-Liu]

Lambda =0.25, 0.49 and 0.50 see file: ccpp/data/GFS_typedefs.F90 variable name xr_exp

[grantfirl]

Ya, @dustinswales, this is new. There was a PR that tuned this for UFS, but NRL wanted the tuning to be optional, so it became a host-controlled variable.