Modifications needed for RRTMG cloud overlap coding #950
Replies: 11 comments 2 replies
-
@mjiacono
Would a reasonable approach be to pass the cloud-fraction from each progcld routine to 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
May I suggest you take a gander at the changes I implemented last year, 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. |
Beta Was this translation helpful? Give feedback.
-
|
@mjiacono part 1 of this issue was addressed in #780, merged 12/28/2021. |
Beta Was this translation helpful? Give feedback.
-
|
@mjiacono I think #830 addressed the remaining issues listed here? |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
It's fine to keep this issue open, thanks for the explanation! |
Beta Was this translation helpful? Give feedback.
-
|
@mjiacono @climbfuji 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 |
Beta Was this translation helpful? Give feedback.
-
|
@dustinswales @climbfuji @grantfirl Issues 3 and 4 have not yet been addressed. I have completed code modifications in response to issues 3 and 4, and I will upload these changes to my fork in the near future. Note that these changes will add cloud condensate sub-grid variability and overlap, and they require calling mcica_subcol before cldprop when this new option is requested. So, I have moved that call out of cldprop. The code should be bit for bit the same if the new cloud condensate option is not used. |
Beta Was this translation helpful? Give feedback.
-
|
@mjiacono Sorry, 3 and 4 are outstanding. Thanks for the clarification. |
Beta Was this translation helpful? Give feedback.
-
|
@mjiacono Mike, will the new cloud overlap features iovr=4 and iovr=5 work for RRTMGp as well ? (@dustinswales and @Qingfu-Liu ) |
Beta Was this translation helpful? Give feedback.
-
|
@yangfanglin @Qingfu-Liu @dustinswales Fanglin, yes the cloud fraction overlap options iovr=4 and 5 are both available in RRTMG and RRTMGP along with the Oreopoulos decorrelation method. The newer cloud condensate overlap option is coded (in RRTMG only for now) and runs in my working copy, but it has not yet been uploaded to github. |
Beta Was this translation helpful? Give feedback.
-
|
@yangfanglin Just to clarify, the treatment (and functionality) of cloud-overlap in RRTMG and RRTMGP are currently identical. The new features that @mjiacono is working on in RRTMG will need to be done for RRTMGP, but I don't see this being a big task. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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).
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions