WRF
WRF copied to clipboard
wrf-model
MP38 Thompson 2-mom graupel/hail (prev #1667)
Option to compute two-moment prognostics for graupel/hail
TYPE: enhancement, new feature
KEYWORDS: microphysics, Thompson microphysics, graupel, hail, double-moment
SOURCE: Code developed by Greg Thompson (JCSDA, UCAR) and Anders Jensen (RAL, NCAR). Implemented in WRF v4.4 by Maria Frediani (RAL, NCAR)
DESCRIPTION OF CHANGES:
This code update includes
a package to compute two-moment prognostics for graupel/hail and a predicted density graupel category (mp_physics=38); an update to the Y-intercept relationship for one-moment graupel; and it replaces air temperature for wet-bulb temperature in riming and mixed phase processes. Problem:
One-dimensional graupel/hail growth does not couple to the storm dynamics and is insufficient for predicting more detailed microphysical storm characteristics and hazards such as hail size, density, and fall speed, which can be used to provide guidance on the timing and spatial extent of damaging hail.
Sensitivity studies have shown that using a constant intercept parameter and a constant density can significantly constrain predicted hail size: simulated storms either produced only pea-size or baseball-size hail (Gilmore et al. 2004).
Improving the representation of riming and mixed phase processes leads to improvements in predicted storm dynamics and propagation speed through microphysical feedbacks and also improves the spatial distribution and type of precipitation at the surface.
Solution:
Changes related with the new package mp_physics=38 include:
Variable density for graupel (rho_g) Parameters become a function of rho_g (am_g, av_g, bv_g, cge, cgg, oamg) Extra dimension in lookup tables to account for graupel variable density (rho_g) New source/sink terms for 3-moment graupel Computation of radar reflectivity and nwp diagnostics using graupel volume mixing ratio Additional modifications affecting mp_physics=8 and mp_physics=28 include:
Fall speed power law relations (av_i from 1847.5 to 1493.9) Reduced dimension of cse, csg (from 18 to 17) Use of wet-bulb temperature for riming and mixed-phase process Modified relationship for the Y-intercept of one-moment graupel to shift the properties of the graupel category to become more hail-like, resulting in a category that represents both graupel and hail. ISSUE: NA
LIST OF MODIFIED FILES: M Registry/Registry.EM_COMMON M phys/module_diag_nwp.F M phys/module_diagnostics_driver.F M phys/module_microphysics_driver.F M phys/module_mp_thompson.F M phys/module_physics_init.F
TESTS CONDUCTED: The modifications were initially demonstrated using the original development made for WRF v4.0 (Jensen et al 2021, under review, MWR-D-21-0319). The operational mp28, mp28 with modified graupel Y-intercept, and mp38 were evaluated for a case study during the PECAN campaign using observed hail sizes from storm reports and estimated from radar. The evaluation showed clear improvement of the simulated reflectivity values in the upper-levels of discrete storms, coinciding with a significant reduction in the areal extent of graupel aloft, also seen when using the updated one-moment scheme. The two-moment and predicted density graupel scheme was also better able to predict a wide variety of hail sizes at the surface, including large (>2-inch in diameter) hail that was observed during this case.
The implementation for this develop branch (aiming at the release v4.4) was tested using a case study from the Relampago campaign and results from mp28, mp38-v4.0, mp38-develop-v4.4 were compared. This comparison indicates that the implementation was successful.
RELEASE NOTE: Include a stand-alone message suitable for the inclusion in the minor and annual releases. A publication citation is appropriate.
Congratulations, Maria! The Jenkins tests have passed:
Test Type | Expected | Received | Failed
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Number of Tests : 23 24
Number of Builds : 60 58
Number of Simulations : 158 156 0
Number of Comparisons : 95 92 0
Failed Simulations are:
None
Which comparisons are not bit-for-bit:
None
Can you say what helped?
On Fri, Apr 29, 2022 at 10:49 AM weiwangncar @.***> wrote:
Congratulations, Maria! The Jenkins tests have passed:
Test Type | Expected | Received | Failed = = = = = = = = = = = = = = = = = = = = = = = = = = = = Number of Tests : 23 24 Number of Builds : 60 58 Number of Simulations : 158 156 0 Number of Comparisons : 95 92 0
Failed Simulations are: None Which comparisons are not bit-for-bit: None
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#issuecomment-1113520914, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77CTAK7HUE33BQPBCQLVHQHLLANCNFSM5UUAHFZQ . You are receiving this because your review was requested.Message ID: @.***>
@gthompsnWRF Could you please review the proposed modification I made to the graupel table (5c47003..82edd98)? The jenkins test passed.
Basically, when is_hail_aware is false, the loop do n3=1, NRHG becomes do n3=1, 1 and the coefficient indices (av_g, bv_g, am_g) are set to idx_bg1 instead of n3. Once the computation is done, it copies the values to the remaining indices, from 2 to NRHG. This means that the table variables will have the same values across the rho_g dimension , representing rho_g(idx_bg1).
I noticed that you hard-coded the 2nd dimension of cgg, and cge to 1 instead of n3 (throughout the code, not only in qr_acr_qg). I'm not sure if that's the intention or not.
The other potential solution (i.e. separate the tables for mp28,8 and mp38) is quite a rabbit hole. I'd have to test is_hail_aware throughout the code because there are multiple max/min statements using NRHG or rho_g(NRHG), and I think it would become a mess very hard to untangle and prone to bugs.
@dudhia I reduced the graupel table computation to 1 dimension when mp=8 or 28. Then I copied the computed values to the remaining 8 elements that would represent the graupel variable-density in mp38. There's a more detailed explanation in my previous post to Greg. Please let me know if you have any questions.
I see a risk there if someone runs 28 and then switches to 38, but it gets us through the regtest which is a good thing.
On Fri, Apr 29, 2022 at 11:19 AM Maria Frediani @.***> wrote:
@dudhia https://github.com/dudhia I reduced the graupel table computation to 1 dimension when mp=8 or 28. Then I copied the computed values to the remaining 8 elements that would represent the graupel variable-density in mp38. There's a more detailed explanation in my previous post to Greg. Please let me know if you have any questions.
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#issuecomment-1113546350, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77FWT4Q25YPC6UZEW2LVHQKZ7ANCNFSM5UUAHFZQ . You are receiving this because you were mentioned.Message ID: @.***>
Good point @dudhia. I'll create distinct table names then. This is simple.
Good point @dudhia. I'll create distinct table names then. This is simple.
This sounds like the best idea. A distinct table name for qr_acr_qg for each of the options is better by far. Thanks for doing this Maria!!
@weiwangncar @dudhia I changed the table names to either qr_acr_qg_mp38V1.dat or qr_acr_qg_mp28V4.dat and tested it for mp38, mp28 and mp8. It's working as expected. Please let me know if anything else is needed for merging it with the develop branch. Thanks!
Jenkins tests have passed for the last change:
Test Type | Expected | Received | Failed
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Number of Tests : 23 24
Number of Builds : 60 58
Number of Simulations : 158 156 0
Number of Comparisons : 95 92 0
Failed Simulations are:
None
Which comparisons are not bit-for-bit:
None
@mefrediani @gthompsnWRF Thanks for making these changes to allow regression tests to pass. Do you have any suggestions how we will go about creating the table for double moment graupel/hail? It still takes a very long time when people first choose the option.
@weiwangncar Could we add another item and a link to download it on this page: https://www2.mmm.ucar.edu/wrf/users/download/get_source.html ?
@weiwangncar do you need anything else from me in order to approve the merge? Do you want to add the table on the webpage asap or later when approaching the next major release?
@mefrediani I don't have concern as of now. If you have the computed tables for the new option, you can pass them to us. We probably won't need them until the next release, but we can keep them on Cheyenne. The reg tests won't test the new option, so I assume you have, with the renamed tables? @dudhia Are you ok with this PR, and with the proposed solution to provide the tables as an alternative?
@mefrediani could you update the PR message to include what was done with the table? I wonder if we also need a manual bit-for-bit test with the new option since it is not in the regtest.
I should have one more look at the code changes just to double-check a few things. Thanks Maria for doing this!!!
I should have one more look at the code changes just to double-check a few things. Thanks Maria for doing this!!!
@gthompsnWRF were you able to do the final checks in the code?
Or you could dummy values that are easy to detect on those filled areas.
On Fri, Apr 29, 2022 at 11:33 AM Maria Frediani @.***> wrote:
Good point @dudhia https://github.com/dudhia. I'll create distinct table names then. This is simple.
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#issuecomment-1113558160, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77CNCOYNBBZD6WOJW5TVHQMP7ANCNFSM5UUAHFZQ . You are receiving this because you were mentioned.Message ID: @.***>
@dudhia I don't understand what you're asking.... Could you please clarify? I'm waiting for @gthompsnWRF to review the code before I run a final bit-for-bit test.
I think Tim answered that your issue was resolved in the last bug-fix release and I think it was related to Greg's question about namelist options.
On Tue, Oct 11, 2022 at 8:59 AM Maria Frediani @.***> wrote:
@dudhia https://github.com/dudhia I don't understand what you're asking.... Could you please clarify? I'm waiting for @gthompsnWRF https://github.com/gthompsnWRF to review the code before I run a final bit-for-bit test.
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#issuecomment-1274837914, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77FIW47QCJHCSSIJOVTWCV6FLANCNFSM5UUAHFZQ . You are receiving this because you were mentioned.Message ID: @.***>
@mefrediani @dudhia Considering the fact that it takes a long time to generate the table data, I suggest that we provide the files and ask the users to download before using the option. Let me know what you think. If you agree, some code changes may be required to stop and report 'not finding input data' to remind users to download.
If it is done this way, the data has to be attached to versions to make sure updates work properly. There could still be an option to generate the table in the code.
@dudhia @weiwangncar I can add a namelist option to generate the table (with default set to false) and an error message to download the table if the option is not switched on to true. When do you need the modification pushed for this PR to make into the new model version?
Ideally before January. It can be handled as a bug-fix later too, but we are thinking of merging this code by January.
On Fri, Dec 16, 2022 at 10:21 AM Maria Frediani @.***> wrote:
@dudhia https://github.com/dudhia @weiwangncar https://github.com/weiwangncar I can add a namelist option to generate the table (with default set to false) and an error message to download the table if the option is not switched on to true. When do you need the modification pushed for this PR to make into the new model version?
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#issuecomment-1355257284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77EQQRIYJZXDJZZSLI3WNSQKLANCNFSM5UUAHFZQ . You are receiving this because you were mentioned.Message ID: @.***>
Regarding the table, maybe that can be added to the run directory as part of the PR to get it through the regtest, but then we don't commit it. Would that work?
Yes, I think there are examples of CASE statements in the diagnostics.
On Wed, Dec 28, 2022 at 1:05 PM Maria Frediani @.***> wrote:
@.**** commented on this pull request.
In phys/module_diag_nwp.F https://github.com/wrf-model/WRF/pull/1728#discussion_r1058563211:
@@ -455,6 +460,39 @@ SUBROUTINE diagnostic_output_nwp( & ! !$OMP END PARALLEL DO ENDIF
- IF (PRESENT(qvolg_curr)) THEN
- WRITE(outstring,*) 'GT-Debug, this mp scheme, ', mphysics_opt, ' has graupel volume mixing ratio'
- CALL wrf_debug (150, TRIM(outstring))
It should be limited to Thompson, @dudhia https://github.com/dudhia. That's because the diagnostic assumes there are 9 possible densities and it's unlikely NSSL makes the same assumptions. Should I add a Case (THOMPSONGH) statement here?
— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1728#discussion_r1058563211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77HNG2ZYF3XRFVR2CJ3WPSMSLANCNFSM5UUAHFZQ . You are receiving this because you were mentioned.Message ID: @.***>
Regarding the table, maybe that can be added to the run directory as part of the PR to get it through the regtest, but then we don't commit it. Would that work?
@dudhia This didn't work. When I push it, Git gives me an error: remote: error: File run/qr_acr_qg_mp38V1.dat is 772.13 MB; this exceeds GitHub's file size limit of 100.00 MB
OK, interesting that there is a limit. We'll see what the test does. Will other Thompson options also try to use that big table? Because those will be in the automatic tests.
@kkeene44 I think I broke my remote branch. I used the web interface to sync with the fork and somehow it synced with master. Do i need to create a new PR to fix this?
OK, interesting that there is a limit. We'll see what the test does. Will other Thompson options also try to use that big table? Because those will be in the automatic tests.
@dudhia No, the big table (qr_acr_qg_mp38V1.dat) is only needed for MP38. There's a different table for MP28 and MP8 (qr_acr_qg_mp28V4.dat).