Modifications needed for RRTMG cloud overlap coding

[mjiacono]

Several corrections or revisions are needed within the current cloud overlap coding in RRTMG_LW in radlw_main.F90 and RRTMG_SW in radsw_main.F90.

1. The EXP cloud overlap option (iovr=4) is currently only allowed to go down a separate path in the code that is labeled in comments as "HWRF" with the initials "mz" (in radlw_main.F90 and radsw_main.F90). This path follows an older coding structure that derives the correlation parameter, alpha, where it is used and that only allows a constant decorrelation length. This appears to me to be close to what was originally coded for HWRF several years ago and went operational in HWRF in 2018. In other words, the existing implementation of iovr=4 is obsolete. HWRF is currently operational with ER (iovr=5), using coding prepared for WRF and not using ccpp-physics.

2. The other cloud overlap options including ER go down a different path that appears to reflect the more recent implementation of generating the decorrelation length (constant or latitude-varying) and alpha prior to the radiation call using dedicated subroutines that are stored in radiation_cloud_overlap.F90 and are called from radiation_clouds.f. However, the iovr=5 option was altered after I provided it and does not work as intended. There is a subtle distinction between EXP and ER that requires altering the derived alpha based on the cloud fraction profile, and this step seems to have been lost in translation from the code I originally provided and is no longer happening anywhere in the code that I can find. Both iovr=4 and iovr=5 call subroutine get_alpha_exp, which only sets up alpha correctly for EXP. In other words, selecting iovr=5 will use EXP cloud overlap instead of ER, and iovr=4 is entirely prevented from using this code path (due to issue 1).

3. This third issue does not represent a problem, however, a design change occurred after I provided the code that will have to be reversed or revised. A new feature that I'm adding now will extend the vertical overlap to the cloud condensate variables, liquid water path and ice water path. My original code left these variables on the (larger) g-point dimension to allow this future expansion, but the code path represented by issue 2 above, which otherwise has the latest code structure, was altered to reduce the cloud condensate arrays from the g-point dimension to the (smaller) band dimension. Since I am now adding this future expansion, these arrays will have to be changed back to the g-point dimension and restored to the MCICA sub-column generator. However, my preference is that issues 1 and 2 be resolved first before I design the final code revisions for my new modifications.

4. Related to issue 3 is the sequence of how the cloud radiation routines are called, which was revised from my original coding. My preference, from the perspective of code clarity, is that the MCICA sub-column generator be called before the cloud optical properties are generated. The latter is done using either subroutine cldprop (on the band dimension) or subroutine cldprmc (on the g-point dimension). Someone moved routine "mcica_subcol" inside of "cldprop", which works as coded, but in my view the sequence is confusing. A better arrangement is to call "mcica_subcol" first, where the cloud fraction overlap, and if requested the new cloud condensate overlap, arrays can be set up, followed by calls either to cldprop, if only cloud fraction overlap is needed, or cldprmc, if both cloud fraction and cloud condensate overlap are requested.

[dustinswales]

1. The EXP cloud overlap option (iovr=4) is currently only allowed to go down a separate path in the code that is labeled in comments as "HWRF" with the initials "mz" (in radlw_main.F90 and radsw_main.F90). This path follows an older coding structure that derives the correlation parameter, alpha, where it is used and that only allows a constant decorrelation length. This appears to me to be close to what was originally coded for HWRF several years ago and went operational in HWRF in 2018. In other words, the existing implementation of iovr=4 is obsolete. HWRF is currently operational with ER (iovr=5), using coding prepared for WRF and not using ccpp-physics.

@mjiacono
There is a namelist parameter to control the decorrelation length used in the overlap assumption, https://github.com/NOAA-EMC/fv3atm/blob/377282920d6130e36b2913cb437d3e6792eb864d/ccpp/data/GFS_typedefs.F90#L710.
There are three options in there at the moment, more details in https://github.com/NCAR/ccpp-physics/blob/3423a13700f9b8d4a7329ac155f3923a45c392ec/physics/radiation_cloud_overlap.F90.
All of the progcld routines use "idcor" imported from physparam.f. You will only need to update the namelist and "plumb" idcor into the RRTMG code, unless you want to add more ways to compute the decorrelation length.

2. The other cloud overlap options including ER go down a different path that appears to reflect the more recent implementation of generating the decorrelation length (constant or latitude-varying) and alpha prior to the radiation call using dedicated subroutines that are stored in radiation_cloud_overlap.F90 and are called from radiation_clouds.f. However, the iovr=5 option was altered after I provided it and does not work as intended. There is a subtle distinction between EXP and ER that requires altering the derived alpha based on the cloud fraction profile, and this step seems to have been lost in translation from the code I originally provided and is no longer happening anywhere in the code that I can find. Both iovr=4 and iovr=5 call subroutine get_alpha_exp, which only sets up alpha correctly for EXP. In other words, selecting iovr=5 will use EXP cloud overlap instead of ER, and iovr=4 is entirely prevented from using this code path (due to issue 1).

Would a reasonable approach be to pass the cloud-fraction from each progcld routine to

ccpp-physics/physics/radiation_cloud_overlap.F90

Line 87 in 3423a13

subroutine get_alpha_exp(nCol, nLay, dzlay, dcorr_lgth, alpha)

as an optional argument. This way we could query internally on whether its EXP or ER.

Did I miss anything? Happy to help bringing these changes into ccpp.

[mjiacono]

The parameter "idcor" is already available to RRTMG here; I'm the one who added it to the code. However, it isn't needed within RRTMG proper, it's used in radiation_clouds.f within the various "progcld" routines where the decorrelation length is specified prior to calling the subroutine that defines alpha. The alpha is then passed into RRTMG and used in the sub-column generator; by this time alpha has already been set up for EXP or ER depending on which was requested.

I propose renaming "get_alpha_exp" to either "get_alpha", or "get_alpha_exp_er". Passing in the cloud fraction as an optional argument to internally query whether alpha will be set up for EXP or ER seems reasonable.

[dustinswales]

The parameter "idcor" is already available to RRTMG here; I'm the one who added it to the code. However, it isn't needed within RRTMG proper, it's used in radiation_clouds.f within the various "progcld" routines where the decorrelation length is specified prior to calling the subroutine that defines alpha. The alpha is then passed into RRTMG and used in the sub-column generator; by this time alpha has already been set up for EXP or ER depending on which was requested.

May I suggest you take a gander at the changes I implemented last year,
NOAA-EMC/fv3atm@3bd9665

Looking at this in greater detail. It looks like I added all that you would need to change the decorrelation length via the namelist in RRTMG.
The flexibility is there, it's just not exercised in any of the current nml configurations.

[climbfuji]

@mjiacono part 1 of this issue was addressed in #780, merged 12/28/2021.

[climbfuji]

@mjiacono I think #830 addressed the remaining issues listed here?

[mjiacono]

@climbfuji #830 has addressed parts 1 and 2 listed in this issue. The remaining issues 3 and 4 are more related to redesign needed for the cloud condensate overlap capability that I will be providing next. If you like, we can close this issue, and I will provide modifications that address 3 and 4 along with the new cloud condensate overlap in a future PR.

[climbfuji]

@climbfuji #830 has addressed parts 1 and 2 listed in this issue. The remaining issues 3 and 4 are more related to redesign needed for the cloud condensate overlap capability that I will be providing next. If you like, we can close this issue, and I will provide modifications that address 3 and 4 along with the new cloud condensate overlap in a future PR.

It's fine to keep this issue open, thanks for the explanation!

[dustinswales]

@mjiacono @climbfuji
The remaining modifications needed were added in February.

The routine to compute the cloud overlap parameter was reverted to its original form, where both the exponential and exponential-random cloud overlap parameters can be computed by the routine.

Point 4 has not been resolved, and I'm not sure that McICA needs to be called BEFORE the cloud-optics. In that case the optical calculations are being computed on 128/112 points, instead on 16/14, for longwave/shortwave. But then again, the cloud-optics calculation are pretty cheap, so maybe it's not a problem to do it this way.

Since the cloud-overlap code modifications have been implemented, I'm going to move this question of the order of cloud-optics/cloud-sampling over to a github discussion