RTMA applications: calculate a "synthetic" cloud fraction #1367
Conversation
…on field, intended for use when true cloud fraction is not provided by the model (e.g., RTMA applications)
|
@GangZhao-NOAA — I have not fully tested this code yet, but I wanted to make it available via a draft PR. Please feel free to test it if you have a moment. Thanks! |
|
jaymes-kenyon
changed the title
…dius from 30 km to 16.1 km
|
Tests on Jet suggest that this PR is working as intended. For example, the screenshots below show the resulting GRIB2 fields of LCDC (left) and FRACCC (at k = 10). In turn, both of these fields are produced from the "CFR" array (cloud fraction) that is calculated in UPP using this fraction-of-exceedance approach. Note that the choice of a 16.1-km neighborhood radius is arbitrary, but seems to give aesthetically good results. 
|
jaymes-kenyon
changed the title
jaymes-kenyon
requested review from
BenjaminBlake-NOAA and
WenMeng-NOAA
as code owners
|
@jaymes-kenyon |
WenMeng-NOAA
requested review from
AnnetteGibbs-NOAA,
GangZhao-NOAA and
MatthewMorris-NOAA
|
@jaymes-kenyon I conducted the testing for 3drtma and found the baseline changes compared to the current release/3drtma_v1 as: I assume that the above changes are expected due to the new cloud fraction calculation for 3drtma. |
|
@WenMeng-NOAA — Thanks for the test results. I expected differences in the fields that are derived from cloud fraction (i.e., FRACCC, TCDC, LCDC, MCDC, and HCDC). But, the other differences (e.g., upper-level UGRD and VGRD) are surprising. Am I interpreting the results correctly? |
|
@WenMeng-NOAA @jaymes-kenyon I think the differences to UGRD/VGRD at 250 and 300 mb are related to the dxm calculation, which Wen re-located in the develop branch as part of PR #1361 . Since this PR is to release/3drtma_v1, perhaps the dxm code changes should be included here too? |
@BenjaminBlake-NOAA Good catching. We might sync that changes from the develop branch after this PR merged. |
|
@WenMeng-NOAA Thank you for running the test and comparing the results! Following @jaymes-kenyon question, I noticed that in WRFTWO.GrbF00, the variables "TCDC" (actually there are two TCDC) are also changed. 3DRTMA needs the updated TCDC product, this should be what we are expecting. Hi @jaymes-kenyon I also noticed that the "Cloud Ceiling" fields are also changed. This is expected, right? There is an interesting thing that, without your "synthetic" scheme to update the cloud fraction in UPP, we still notice that the "cloud Ceiling" is updated after UPP. Does it mean that UPP already has the function to diagnose the "cloud Ceiling" with the updated cloud water and ice? Then with your newly-implemented "synthetic" scheme to update 3D cloud fraction in UPP, will this "could ceiling" be furtherly adjusted by the updated 3-D cloud fraction fields? Or the update in cloud fraction does not have influence on the cloud ceiling? Hi @WenMeng-NOAA , another question -- I see two cloud ceiling "CEIL" and "HGT" in WRFTWO.GrbF00. Only the "CEIL" is valid for final product, the "HGT" is something invalid and should be removed, right? Hi @jaymes-kenyon, I am thinking about adding an namelist option to switch on/off this "synthetic" cloud fraction scheme in UPP. It was mentioned in this PR before. Maybe I can add it later after this PR is merged. Thank you! -Gang |
|
@jaymes-kenyon @GangZhao-NOAA @BenjaminBlake-NOAA Sorry for the misleading information. The last comparison results are between this PR and the develop branch. |
Cloud fraction is involved in simulated satellite BT calculation. So the above changes are expected. |
@GangZhao-NOAA There are actually two parameters available for cloud ceiling height - HGT:cloud ceiling and CEIL:cloud ceiling. Here's some more detailed information about each (from @jaymes-kenyon ):
|
|
@BenjaminBlake-NOAA @jaymes-kenyon |
|
Regarding the ceiling fields, I noticed that RTMA is apparently configured to use parameter 260 to calculate "HGT:cloud ceiling". This ceiling algorithm is different from GSL's algorithm (parameter 408...the so-called 'legacy' ceiling) used in HRRRv4. It might be worth using 408 instead of 260 to more closely align RTMA with HRRRv4. Relatedly, it might be good to disable "CEIL:cloud ceiling". This field relies on the netCDF "CLDFRA_BL" array (from the MYNN scheme). Since the goal of this PR is to avoid using "CLDFRA_BL" for RTMA diagnostics, it seems logical to not generate "CEIL:cloud ceiling" in the RTMA. Does this all make sense? |
|
It appears to me, in 3drtma_postcntrl.xml, there are three cloud ceiling products:
Somehow, there are two cloud ceiling related fields generated in WRFTWO.GrbF00 |
|
My experiment indicates that 408 (GSD_HGT_ON_CLOUD_CEILING) is missing in WRFTWO.GrbF00. |
|
I noticed that parameters 260 and 408 both use the same "HGT" and "cloud ceiling" descriptors in the post_avblflds.xml file: With these settings, I think the fields would both be encoded as "HGT:cloud ceiling". Perhaps this means that the field is being overwritten, resulting in one GRIB2 field (not two). I could try a test with parameter 260 removed. |
Update: Actually, 408 is being encoded as the cloud base. This is because the <fixed_sfc1_type> in 3drtma_postcntrl.xml is "cloud_base", which overrides the default of "cloud_ceiling" in post_avblflds.xml. So, in summary: We are getting the cloud base via 408, the ceiling via 260, and a supplemental ceiling via 487. My suggestion is that we disable 487 in the RTMA, since we wish to avoid calculations derived from the netCDF "CLDFRA_BL" array. |
|
@jaymes-kenyon Great catch. Your proposal to remove 487 makes sense to me and I would defer the decision to the EMC rtma team @GangZhao-NOAA @MatthewMorris-NOAA @AnnetteGibbs-NOAA |
|
@jaymes-kenyon @WenMeng-NOAA @BenjaminBlake-NOAA
Question 1: we did not miss the 3 cloud ceiling height related products in current 3DRTMA UPP, right? Question 2: with Jaymes' updated code to derive the 3-D cloud fraction (CFR) from the analyzed cloud ice/water in UPP, we get the the 2-D Total Cloud Coverage (TCDC) updated, this is what we expected. I would like to make it clear that, if this new algorithm also make further change to the other cloud fields, such as the "Cloud Ceiling", 260, 408 and 487. Any "collateral effect" to all or any of these 3 ceiling height fields? Question 3: 260 vs 408: 408 is using " the GSL's algorithm for parameter 408...the so-called 'legacy' ceiling used in HRRRv4". So to be more closely aligned with HRRR product, 408 is preferred to 260. Question 4: about 487: this "CEIL:cloud ceiling" is derived from the 3-D array "CLDFRA_BL" in netcdf file. If this "CLDFRA_BL" is NOT analyzed and updated in GSI/Cloud Analysis, then this 487 field should also not be changed. Then in Wen's test results with your updated UPP code, we see that there is Signiant differences: Sorry to keep bothering you in this PR. -Gang |
| #else | ||
| real, parameter :: QCLDmin=1.E-5 !< Minimum cloud mixing ratio - was 1.E-6 | ||
| #endif | ||
| real, parameter :: CLOUD_DEF_P=1.E-7 !< Cloud water + ice mixing ratio (qc + qi) threshold used by some GSL diagnostics |
There was a problem hiding this comment.
@jaymes-kenyon
Here CLOUD_DEF_P=1.E-7. I noticed that in GSI cloud analysis "gsdcloudanalysis.F90",
at line 208
data cloud_def_p / 0.000001_r_kind/
which is 1.0E-6. You did mentioned that "the value of cloud_def_p is also arbitrary" in INITPOST.F. I just want to confirm with you that this inconsistency is just a trivial thing, since it could be arbitrary.
Thank you!
-Gang
GangZhao-NOAA
left a comment
GangZhao-NOAA
left a comment
There was a problem hiding this comment.
The changes look good to me. Approval for merging.
I did have a trivial question about the value of CLOUD_DEF_P (1.E-7 or 1.E-6). It is just a very minor thing. And if necessary, it could be adjusted later.
4 participants
This PR addresses issue #1364.
In particular, it serves to re-introduce a diagnostic procedure that was previously coded in UPP. The procedure calculates a "synthetic" cloud fraction for use in modeling applications that do not provide a "true" cloud fraction. This is accomplished by using the arrays of cloud-water and cloud-ice mixing ratio, then performing a neighborhood search to produce a neighborhood fraction of exceedance. This fraction is then assigned to the cloud-fraction array for subsequent use elsewhere in UPP.
Copying several RTMA developers: @GangZhao-NOAA @guoqing-noaa @ManuelPondeca-NOAA @AnnetteGibbs-NOAA @MatthewMorris-NOAA @hu5970