Thompson MP: new one-moment Graupel y-intercept

[gthompsnWRF]

TYPE: new feature

KEYWORDS: Thompson microphysics, graupel, Y-intercept parameter

SOURCE: Greg Thompson (NCAR-RAL)

DESCRIPTION OF CHANGES:
Significant alteration of how Y-intercept parameter is diagnosed for one-moment graupel.
Attempt is made to follow observations of Field et al. (2018JAMC). Y-intercept is now directly
proportional to mass mixing ratio as opposed to being inversely proportional. Also expands the
lookup tables for rain collecting either snow or graupel and the total range of Y-intercept values.

ISSUE:
Fixes issue #966 "module_mp_thompson lookup tables (qr_acr_qs.dat and qr_acr_qg.dat) with
PR: graupel_Yintercept_new". Due to the expansion of the elements in 3 vectors (called "r_s,"
"r_g," and "N0g_exp") along with the number of elements held in variables "ntb_s," "ntb_g,"
and "ntb_g1," respectively, the look-up table files called "qr_acr_qs.dat" and "qr_acr_qg.dat"
have now been updated to include "V2" in their names to avoid conflict with old lookup table
files.

LIST OF MODIFIED FILES:
phys/module_diag_misc.F
phys/module_mp_thompson.F

TESTS CONDUCTED:

1. Numerous real cases and idealized 3D squall line cases were run with the new Y-intercept.
2. Since new data files are generated / used, a test case was run with the new code and with
   the old data in the directory. With a 3km DX, 12s DT for 20 minutes dumping history files each
   5 mins., the simulation ran fine reporting: d01 2015-06-19_12:20:00 wrf: SUCCESS COMPLETE
   WRF when the 20 minutes was reached. The wrfout files, viewed with with ncview, look as
   expected.

RELEASE NOTE: For Thompson MP, a significant alteration is introduced for diagnosing the Y-intercept parameter for the one-moment graupel. These changes affect results for any graupel area. The changes are based on observations of graupel/hail size spectra from aircraft observations.

[davegill]

@dudhia @weiwangncar @gthompsnWRF
As Greg mentioned in his PR, we cannot merge this code without an ability to detect old vs new lookup tables.

[davegill]

@dudhia @weiwangncar @gthompsnWRF

From Greg: do you think we should just increment the names of the tables to become something simple like: qr_acr_qsV2.dat and qr_acr_qgV2.dat. That would take little effort in the module_mp_thompson code.

Greg,
Jimy and I think that this idea would work just fine. Would you please include those mods into this PR.

[gthompsnWRF]

@davegill @dudhia I now committed the modification and pushed it up to GitHub. Should be ready to go I believe.

[davegill]

@gthompsnWRF
Greg,
Would you please run the new code in a directory where the old files exist, to verify that things do actually work as advertised. Just need a couple of time steps.

[davegill]

@weiwangncar @dudhia

RELEASE NOTE: For Thompson MP, a significant alteration of how the Y-intercept parameter is diagnosed for the one-moment graupel. These changes definitely affect results for any graupel areas, however, it is effectively impossible to determine objectively if things like radar reflectivity, precip amount, etc. are improved. The intent here is to become closer to observations of graupel/hail size spectra in aircraft observations, which we believe is achieved. If modeled graupel/hail spectra are improved, one should expect improvement to related aspects such as cold-pool development, reflectivity, precip, and others, however, evaluations at convective scales are relatively difficult.

How about this for a release note:
For Thompson MP, a significant alteration is introduced for diagnosing the Y-intercept parameter for the one-moment graupel. These changes affect results for any graupel areas. The changes are based on observations of graupel/hail size spectra from aircraft observations.

[gthompsnWRF]

@weiwangncar @dudhia

RELEASE NOTE: For Thompson MP, a significant alteration of how the Y-intercept parameter is diagnosed for the one-moment graupel. These changes definitely affect results for any graupel areas, however, it is effectively impossible to determine objectively if things like radar reflectivity, precip amount, etc. are improved. The intent here is to become closer to observations of graupel/hail size spectra in aircraft observations, which we believe is achieved. If modeled graupel/hail spectra are improved, one should expect improvement to related aspects such as cold-pool development, reflectivity, precip, and others, however, evaluations at convective scales are relatively difficult.

How about this for a release note:
For Thompson MP, a significant alteration is introduced for diagnosing the Y-intercept parameter for the one-moment graupel. These changes affect results for any graupel areas. The changes are based on observations of graupel/hail size spectra from aircraft observations.

Dave, this is certainly fine with me. Also, I would have a test finished ASAP for trying out the new code mods, except that Cheyenne's compute nodes are taken off-line for this week. Will get it done as soon as I can.

[davegill]

@gthompsnWRF

I would have a test finished ASAP for trying out the new code mods, except that Cheyenne's compute nodes are taken off-line for this week.

Greg,
I feel your pain. 🤠 🖥 🍞 🔥

[gthompsnWRF]

@davegill FYI: I ran the wrf.exe from this PR using 3km DX, 12s DT for 20 minutes dumping history files each 5 mins. The simulation ran fine reporting: d01 2015-06-19_12:20:00 wrf: SUCCESS COMPLETE WRF when the 20 minutes was reached. I viewed wrfout files with ncview and things do look as I expected.

[davegill]

@gthompsnWRF

I ran the wrf.exe from this PR using 3km DX, 12s DT for 20 minutes dumping history files each 5 mins. The simulation ran fine reporting: d01 2015-06-19_12:20:00 wrf: SUCCESS COMPLETE WRF when the 20 minutes was reached. I viewed wrfout files with ncview and things do look as I expected.

Greg,
To be clear. This test had the original / old *.dat files in the directory, and the new Thompson MP code correctly used or created the new data, right?

[gthompsnWRF]

@gthompsnWRF

I ran the wrf.exe from this PR using 3km DX, 12s DT for 20 minutes dumping history files each 5 mins. The simulation ran fine reporting: d01 2015-06-19_12:20:00 wrf: SUCCESS COMPLETE WRF when the 20 minutes was reached. I viewed wrfout files with ncview and things do look as I expected.

Greg,
To be clear. This test had the original / old *.dat files in the directory, and the new Thompson MP code correctly used or created the new data, right?

@davegill Yes, that is correct. The code created the newer tables with V2 in their name and no hiccups seen. The rsl.out file showed what I expected...
ThompMP: computing qr_acr_qg
Writing qr_acr_qgV2.dat in Thompson MP init
ThompMP: computing qr_acr_qs
Writing qr_acr_qsV2.dat in Thompson MP init

And, for completeness, I will run another run to ensure 100% that the files are NOT created a second time, but, instead they are read since they now exist in the directory. That logic wasn't changed, only the name, but for sake of being certain, I will run again.

[davegill]

From a software / infrastructure point of view, this is approved.

[davegill]

@dudhia @weiwangncar
Jimy and Wei,
Would you please review this PR to the develop branch.

[smileMchen]

@davegill @gthompsnWRF
I can run regression test for this PR. Please let me know if it is necessary.

[davegill]

@smileMchen

I can run regression test for this PR. Please let me know if it is necessary.

Ming,
Great idea.

[dudhia]

Looks OK to me.

…

On Mon, Aug 12, 2019 at 9:41 AM Dave Gill ***@***.***> wrote: @dudhia <https://github.com/dudhia> @weiwangncar <https://github.com/weiwangncar> Jimy and Wei, Would you please review this PR to the develop branch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#965?email_source=notifications&email_token=AEIZ77GESM2EHXNJH33GZ3TQEGAB5A5CNFSM4IHVITA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4C57TA#issuecomment-520478668>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEIZ77AMQQHYFX2KWPT5U6DQEGAB5ANCNFSM4IHVITAQ> .

[jamiebresch]

Are N0_min, gonv_min and gonv_max still need to be declared? Why are the declared values of gonv_min and gonv_max changed when they are removed in the code?

[davegill]

@gthompsnWRF @jamiebresch

Are N0_min, gonv_min and gonv_max still need to be declared? Why are the declared values of gonv_min and gonv_max changed when they are removed in the code?

Greg,
Because of Jamie's usual eagle eye, I looked through the code. You no longer use N0_min, gonv_min, or gonv_max. You have N0min declared in one file and N0_min declared in the other.

[gthompsnWRF]

@jamiebresch @davegill The variables remain declared and unused, yes. But if we're suddenly going to go through codes and worry about a couple of unused variables, I think other parts of WRF will reveal a great many more. I prefer leaving them at this time, please. There could be a reason to bring their usage back in future. It's only 3 scalars, not arrays so memory footprint is trivial.

[davegill]

@gthompsnWRF
Greg,
Jamie's point is that you both modified the values and then stopped using them. The concern is that one of these was an oops. That's all.

[gthompsnWRF]

@gthompsnWRF
Greg,
Jamie's point is that you both modified the values and then stopped using them. The concern is that one of these was an oops. That's all.

Gotcha. It wasn't really an oops. I debated using the changed values for the limits/goalposts on one of the derived variables, but decided it wasn't actually needed. Perhaps, though doubtful, I could see reviving the old usage some day in future. Thanks for clarifying.

[smileMchen]

@davegill @gthompsnWRF
regression test passed.