Add constraints and namelist variables for Thompson MP #619

RuiyuSun · 2021-04-12T16:26:34Z

This can also be found at #618

Adding constraints and negative tracers adjustment as options and two
namelist variables to Thompson MP.

Constraints include:

ice deposition, snow deposition, rain freezing, cloud water freezing, and
instant melting of snow when T> 2C.
Zeroing out statements in the scheme adds mass into the system if there are
negative values in the tracers. The negative adjustment option added a
subroutine to adjust the negative values in tracers to borrow the mass of
tracers with negative values from others. The option also commented off
lines of code that adding vapor when vapor is negative. Details are shown
in the code.
A namelist variable is added for the critical cloud water (crtclw) that
controls cloud to rain conversion. Another namelist variable(srhci) is
added for the critical supersaturation in ice nucleation.

Fixes #618.

climbfuji · 2021-04-14T21:38:49Z

@gthompsnWRF I cannot add you as reviewer since you haven't accepted the invite to "collaborate" on NCAR ccpp-physics, hence I am notifying you this way about these proposed changes.

climbfuji

@RuiyuSun please provide an adequate description of the changes that are made in this PR, so that the reviewers have to do less guess work. Also, please mention any open issues that the PR is supposed to fix, and links to the associated fv3atm and ufs-weather-model PRs. Thanks!

RuiyuSun · 2021-04-19T17:47:01Z

Is the following description good enough? This can also be found at #618 adding constraints and negative tracers adjustment as options and two namelist variables to Thompson MP. Constraints include: ice deposition, snow deposition, rain freezing, cloud water freezing, and instant melting of snow when T> 2C. Zeroing out statements in the scheme adds mass into the system if there are negative values in the tracers. The negative adjustment option added a subroutine to adjust the negative values in tracers to borrow the mass of tracers with negative values from others. The option also commented off lines of code that adding vapor when vapor is negative. Details are shown in the code. A namelist variable is added for the critical cloud water (crtclw) that controls cloud to rain conversion. Another namelist variable(srhci) is added for the critical supersaturation in ice nucleation.

…

On Mon, Apr 19, 2021 at 11:30 AM Dom Heinzeller ***@***.***> wrote: ***@***.**** requested changes on this pull request. @RuiyuSun <https://github.com/RuiyuSun> please provide an adequate description of the changes that are made in this PR, so that the reviewers have to do less guess work. Also, please mention any open issues that the PR is supposed to fix, and links to the associated fv3atm and ufs-weather-model PRs. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#619 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFOCLFT3VMXZPCLHGILE5DTJRECXANCNFSM42ZT6TDQ> .

-- Ruiyu Sun, PhD *IMSG* at NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2097 College Park, MD 20740 ***@***.*** ***@***.***> 301-683-3787

climbfuji · 2021-04-19T17:52:39Z

Is the following description good enough? This can also be found at #618 adding constraints and negative tracers adjustment as options and two namelist variables to Thompson MP. Constraints include: ice deposition, snow deposition, rain freezing, cloud water freezing, and instant melting of snow when T> 2C. Zeroing out statements in the scheme adds mass into the system if there are negative values in the tracers. The negative adjustment option added a subroutine to adjust the negative values in tracers to borrow the mass of tracers with negative values from others. The option also commented off lines of code that adding vapor when vapor is negative. Details are shown in the code. A namelist variable is added for the critical cloud water (crtclw) that controls cloud to rain conversion. Another namelist variable(srhci) is added for the critical supersaturation in ice nucleation.
…

Thank you, I copied this into the first/top text box of the PR and linked issue #618 to it.

ligiabernardet · 2021-05-07T20:36:25Z

Given the discussion in a 5/7/2021 meeting involving various people developing and debugging the Thompson mp scheme, we will put this PR on pause until the week of May 24th. We are trying to get a better understanding of what is causing the crashes and temperature out-of-bounds warnings when using Thompson mp with the UFS.

gthompsnWRF · 2021-06-04T13:57:48Z

physics/module_mp_thompson.F90

@@ -227,6 +227,9 @@ MODULE module_mp_thompson
      REAL, PARAMETER:: re_qs_min = 5.00E-6               ! 5 microns
      REAL, PARAMETER:: re_qs_max = 999.0E-6              ! 999 microns (1 mm)

+!..snow melting
+      REAL, PARAMETER, PRIVATE:: Tsmelt = 275.16


I will say unequivocally that instant melting of snow at +2C is utter nonsense and entirely unacceptable to me. This is not scientifically justified at all. And proclaiming it to be set to happen via a namelist option is not acceptable to me since it is fully unphysical.

This method was adapted from another widely used microphysics scheme. It may not be so scientifically adjusted but for some reasons helps with the stability.

This method was adapted from another widely used microphysics scheme. It may not be well scientifically adjusted but for some reasons helps with the stability.

This is to help prevent the snow fall to a temperature that is too high for snow in the global simulation with a large time step. I understand there might be better method but currently not available to us.

The mention of "but for some reasons helps with the stability" has never been shown in isolation. Only a test with this single change to be proven to work as advertised to improve stability should be cause to accept this change. The consequences of this solution are potentially embarrassing to the USA for wet snow events; which can be highly impactful to surface transportation.

I tested a few temperatures, 2C, 4C, 5C, 7C for example, with the gfsv16_ccpp workflow (C768) using 201907100 ICs from the GFSv16 retrospective experiment.

With 7C and 5C, the experiment failed. The error message is shown below
_FATAL from PE 333: NaN in input field of mpp_reproducing_sum(2d), this indicates numerical instability

In the case of 4C, a segmentation fault occurred.
In the case of 2C, the experiment completed.

The log files are at /scratch1/NCEPDEV/stmp2/Ruiyu.Sun/ROTDIRS/gtnpntp1/logs/2019071100 on Hera (if you have access to it).

gthompsnWRF · 2021-06-04T14:01:16Z

physics/module_mp_thompson.F90

@@ -1014,7 +1017,7 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc,     &
                              has_reqc, has_reqi, has_reqs,           &
                              rand_perturb_on,                        &
                              kme_stoch,                              &
-                              rand_pert,                              &
+                              rand_pert, fcons, ffixneg,crtclw, srhci,&


I wish to advise possible naming changes to variables. Do we need the extra f in ffixneg? The variable "fcons" is not descriptive to me - no idea without digging into code what it is; same with srhci; also same with deld - it is clearly a delta, but I don't know what delta, is it a pressure difference in layers?

ffixneg is a logic flag for using fixing negative tracer values. fcons is a logical flag for using constraints added. srchi is critical supersaturation for deposition nucleation. deld is delta for the dry air.

Again, my comment is for logical naming changes for variables and I'm not really asking for clarification via comments but via actions in changing names. Furthermore "deld is delta for the dry air." Delta what. That's my entire point. Delta of what of dry air?

Thank you for your suggestion. The two names, fcons and ffixneg, have been replaced by use_constraints and fixneg in the local repository. delta is moist air mass * gravity acceleration and deld is dry air mass * gravity acceleration.

gthompsnWRF · 2021-06-04T14:07:18Z

physics/module_mp_thompson.F90

@@ -1275,6 +1281,11 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc,     &
            enddo
         endif

+         if(ffixneg) then


I really think a negative adjustment scheme is not to be performed in the microphysics itself, since this is coming from the dynamics, which are apparently not positive-definite. I will argue that resetting of cloud/precip variables to zero if they are negative may be the RIGHT thing to do - since these are artifacts of the dynamics. In my view, the proper thing to do is resolve this immediately after advection/diffusion code and that way every single option of a model gets the same treatment all at the same step, not put into individual microphysics schemes. Furthermore, I believe water vapor has to be treated uniquely. Water vapor additions are the bigger danger I believe to mass additions by resetting to zero. Furthermore, water vapor would never be identical to zero itself, but some small value. I admit 1.E-7 may not be proper for model systems with incredibly high altitude model tops. My code was written for WRF, not global models with tops around single digit pascals. Therefore, a scale factor could easily be applied to lower limit of water vapor (very important to radiation in those stratospheric and above altitudes) to decrease QV upwards to something as low as 1.E-20. Again, WRF is not a global model and these physics need adjusting for global and massively high tops.

I think this can be moved to the mp_thompson routine. The negative tracer values may be caused by other physics. Your suggestion of a very small qv can be tested.

gthompsnWRF · 2021-06-04T14:15:38Z

physics/module_mp_thompson.F90

@@ -2104,7 +2121,8 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &

 !>  - Autoconversion follows Berry & Reinhardt (1974) with characteristic
 !! diameters correctly computed from gamma distrib of cloud droplets.
-         if (rc(k).gt. 0.01e-3) then
+!        if (rc(k).gt. 0.01e-3) then
+         if (rc(k).gt. crtclw) then


This is not acceptable at all in my opinion. There is no pre-set autoconversion threshold. This is also not protected by any IF-condition for namelist options that I can see at all. Cloud water does not convert to rain at a pre-set threshold in my scheme because that just makes it like a Kessler (1969) scheme. The internal equations will handle the threshold based on the drop sizes, characteristic diameters represented by Dc_g and Dc_b (2 different characteristics of the droplet size distribution). Since those 2 variables are subsequently used to calculate zeta1 and tau, which could go negative, that is what controls the onset of autoconversion, not some cloud water threshold. By implying that one could set the variable called "crtclw" to permit or stop autoconversion is entirely misguided because of that. Furthermore, the value I wrote as 0.01E-3 was intentional because it would never occur in practice. That was just a rapid bypass of further calculations to avoid computation cost if there was never a chance that cloud water autoconverting to rain could ever happen, simply because it is way too low. So the idea of this proposed change is misguided simply because 0.01E-3 was never a threshold for autoconversion, only a CPU-savings.

I went through a few references and derivation of what is used in the code. Cohard and Pinty (2000) mentioned that Ziegler (1985) defined "a criterion for rain initiation based on the number concentration of these intermediate drops". Based on the discussion of R_b by Berry and Richard (1974 part II), do you think that R_b could be used to save computing time?

How is 0.01E-3 determined? Could there be a large value that can be used? I did a test and used 0.005E-3. By the end of the 10day forecast significant difference was shown in the cloud water field.

Several references mentioned the possible double counting of the accretion and rain self-collection. Should this be considered?

Unless my minimum setting of 2 cloud water drops per cubic meter (or kg) of air has changed, the LWC amount of 0.01E-3 will never give a tau or zeta term than can be positive. I can write ~10 lines of code to double-check this. I believe you miss my point above of why I choose this value, so I will write the mini-test to show what I believe to be true with this exact value having no impact.

gthompsnWRF · 2021-06-04T14:26:27Z

physics/module_mp_thompson.F90

@@ -2435,7 +2453,12 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &
           if (prs_sde(k).lt. 0.) then
            prs_sde(k) = MAX(DBLE(-rs(k)*odts), prs_sde(k), DBLE(rate_max))
           else
-            prs_sde(k) = MIN(prs_sde(k), DBLE(rate_max))
+            if(fcons) then
+              tempp = (T_0-temp(k))/(lsub*ocp(k))*odts


I do not know what is being attempted here. The variable called tempp is akin to a temperature tendency but the first term is -1*(temperature_in_centigrade). Do you realize that when temperature is positive, then tempp is negative and then prs_sde immediately becomes negative and yet the test for prs_sde<0 was done just above here? That means that instead of the intended prs_sde which should be positive (per original code) suddenly becomes negative due to the MIN statement at line#2458. This is not only a BUG, but a travesty of intent. The ramifications to later parts of the code when the source/sink terms are added to water vapor, taken away from snow, etc, are now all wrong.

The original intent of code is to ensure we do not add more vapor deposition to snow than the amount of total available water vapor (rate_max). The proposed code is not mathematically sound and could have serious negative consequences later.

This is a process below 0C. It is to prevent the heat released in the deposition raising the temperature above 0C. Tempp is the maximum tendency that is allowed to avoid raising the temperature above 0C.

Sentences #2 and #3 of my comment were not addressed in the reply at all. What is being done by the code changes is mathematically incorrect in T>0C conditions and capable of either depleting or inserting mass (via water vapor).

This is inside of if (temp(k).lt.T_0) then block. (T_0-temp(k)) is positive. So is tempp. I admit that 'tempp' is a confusing name. It is not a temperature tendency but the maximum tendency of deposition that is allowed to avoid raising the temperature above 0C. I hope I answered your question.

gthompsnWRF · 2021-06-04T14:27:15Z

physics/module_mp_thompson.F90

@@ -2446,7 +2469,12 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &
           if (prg_gde(k).lt. 0.) then
            prg_gde(k) = MAX(DBLE(-rg(k)*odts), prg_gde(k), DBLE(rate_max))
           else
-            prg_gde(k) = MIN(prg_gde(k), DBLE(rate_max))
+            if(fcons) then


I have the same comment as the previous one because this is mathematically unacceptable and unphysical.

What fcons does here is similar to the previous one.

gthompsnWRF · 2021-06-04T15:00:21Z

physics/module_mp_thompson.F90

-           pri_rfz(k) = tpi_qrfz(idx_r,idx_r1,idx_tc,idx_IN)*odts
+           if(fcons) then
+             lfus2 = lsub - lvap(k)
+             tempp = (T_0-temp(k))/(lfus2*ocp(k))


I can see what is attempted here via tempp, but do you realize the consequences? All instances of tempp are limiting the souce/sink terms to something related to number of degrees below freezing (absolute value of temperature_in_centigrade). Therefore, at only 1C, the freezing of rain to graupel is limited to equivalent of 1C temperature tendency, having absolutely nothing to do with the mass of rain that is freezing. And, yet at -30C, there could be up to 30C temperature tendency equivalent of freezing rain, again without regard to the actual mass of rain that is freezing. In other words, compared to the real world, where much more rain is likely to exist at -5C than at -35C, the limit applied to freezing of rain is incredibly constrained. What's physical about this proposed change - how does one degree of temperature change related to some mass of rain that freezes?

The intent is now abundantly clear. Trying to limit temperature tendency by changing the physics of any microphysics source term that can contribute to the temperature tendency but do it more heavy-handed near the melting level than farther removed (higher altitude with lower temperature will have lesser constraints). This is not physics at all.

I cannot word this strongly enough. All of these individual usages of tempp are unphysical. These are all just piecemeal attempts to constrain temperature tendency is one section at a time rather than just applying a global temperature tendency limiter that has long been used by RAP/HRRR in the namelist option for "mp_tend_limit."

I urge other reviewers to reject these changes and just use the RAP/HRRR solution instead of permanently putting in changes to code that has physical justification based on textbook equations in Prupacher and Klett.

The rain freezing is a below 0C process. The code added is to prevent the heat released in the freezing raising temperature above 0C. Tempp is maximum tendency that is allowed to avoid raising temperature above 0C.

gthompsnWRF · 2021-06-04T15:05:39Z

physics/module_mp_thompson.F90

@@ -2533,7 +2574,8 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &

 !>  - Deposition nucleation of dust/mineral from DeMott et al (2010)
 !! we may need to relax the temperature and ssati constraints.
-          if ( (ssati(k).ge. 0.25) .or. (ssatw(k).gt. eps &
+!         if ( (ssati(k).ge. 0.25) .or. (ssatw(k).gt. eps &
+          if ( (ssati(k).ge. srhci) .or. (ssatw(k).gt. eps &


I don't believe there is any way that this threshold for RH with respect to ice used at the time to initiate cloud ice could be causing any model blow ups. This IF block is also not protecting for use as a namelist option, which I thought all changes would be.

This namelist intends to relax the constraints for ice generations in the forecast systems with large grid sizes.
The default value of srhci is 0.25 if no value assigned through namelist from outside.

gthompsnWRF · 2021-06-04T15:09:50Z

physics/module_mp_thompson.F90

@@ -3701,6 +3747,34 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &
          ncten(k) = ncten(k) - xnc*odt
          tten(k) = tten(k) + lfus2*ocp(k)*xrc*odt*(1-IFDRY)
         endif
+         if (fcons) then
+! The instant melting of snow is adopted from MG3 by Drs. H. Morrison and A. Gettelman
+           xrs = MAX(0.0, qs1d(k) + qsten(k)*DT)


At the definition of Tsmelt, I provided opinion that this code should not be used. We can still melt snow slowly when T>2C. If long time steps allows snow to exist at very warm temperatures, there are other methods we can use to resolve this situation. Snow physically melts at wet bulb temperature >0C, so in very low RH conditions, snow can survive to surprisingly high temperature.

It will be physically make more sense if wet bulb temperature and RH can be considered in the snow melting process. Ice in the current code is melted at 0C. Do you think wet bulb temperature and RH should also be considered in the ice melting?

This is the term in the equation for prr_sml that accounts for the RH/wetbulb temperature. Some persons may use the wetbulb temp explicitly, but this term is what accounts for it in my equation/code... delQvs

gthompsnWRF · 2021-06-04T15:44:11Z

physics/module_mp_thompson.F90

+      do k = kbot, ktop +1, -1 
+        if (qv (k) < 0.) then
+            qv (k - 1) = qv (k - 1) + qv (k) * dp (k) / dp (k - 1)
+            qv (k) = 0.


I don't think QV should ever be set identical to zero. In the lower troposphere, this really is not very good.

A very small value can be tested.

climbfuji

My comments are only w.r.t. the code, not the science.

I also want to mention that several changes have been made in the last two months (e.g. use of assumed-size arrays), that will (a) lead to merge conflicts when pulling in the updates from main, and (b) will require changing some of the newly added code as well (in particular lines 409-411).

climbfuji · 2021-06-04T19:13:58Z

physics/module_mp_thompson.F90

@@ -1275,6 +1281,11 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc,     &
            enddo
         endif

+         if(ffixneg) then


It is not clear to me why this negative adjustment is done here. Since it is before the actual call to Thompson microphysics, it looks more like a "sanitize whatever the model produces before calling Thompson MP" step. If really necessary shouldn't this be done outside/before the/any microphysics scheme?

It is not clear to me why this negative adjustment is done here. Since it is before the actual call to Thompson microphysics, it looks more like a "sanitize whatever the model produces before calling Thompson MP" step. If really necessary shouldn't this be done outside/before the/any microphysics scheme?

I can at least answer that resetting negative MP variables to zero is something found in my existing code - and is found in other WRF microphysics schemes as well. However, elevating something like ensuring non-negative values to a place above/before any calls to any MP-scheme seems like a step for someone to consider. These negative values are presumed to come from non-positive-definite advection schemes and really aren't related to microphysics schemes themselves. And, yet, to protect against bad data, this is a necessary step in the past in WRF because users can choose from a menu of advection options, some of which are not positive-definite.

Agree. In our recent tests, we see the problem of negative qv going into the microphysics with MYNN PBL, but not with the operational GFS PBL scheme. Joe is working on addressing this problem properly instead of just sanitizing the model state after the PBL scheme is run.

The negative adjustment could be moved into mp_thompson.F90. The negative tracer could be caused by other physics called before microphysics. GFDL microphysics also used this in the scheme.

climbfuji · 2021-06-04T19:15:28Z

physics/module_mp_thompson.F90

@@ -1409,16 +1421,18 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc,     &
             write(*,'(a,e16.7,a,3i8)') 'WARNING, negative ni ', ni1d(k),        &
                        ' at i,j,k=', i,j,k
            endif
-            if (qv1d(k) .lt. 0.0) then
-             write(*,'(a,e16.7,a,3i8)') 'WARNING, negative qv ', qv1d(k),        &
+            if(.not. ffixneg) then


Even if ffixneg is .true., I would still perform this test. Just in case changes are made to mp_thompson that break the ffixneg logic inside the scheme.

the two lines are moved out of 'if(.not. ffixneg) then' block.

climbfuji · 2021-06-04T19:26:15Z

physics/module_mp_thompson.F90

@@ -3701,6 +3747,34 @@ subroutine mp_thompson (qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &
          ncten(k) = ncten(k) - xnc*odt
          tten(k) = tten(k) + lfus2*ocp(k)*xrc*odt*(1-IFDRY)
         endif
+         if (fcons) then
+! The instant melting of snow is adopted from MG3 by Drs. H. Morrison and A. Gettelman


I find it strange to add people's titles in code comments.

titles are removed.

climbfuji · 2021-06-04T19:26:35Z

physics/module_mp_thompson.F90

+! fix negative water species
+! this is designed for 6 - class micro - physics schemes
+! adapted from GFDL MP 
+! This routine is taken from GFDL MP. The rouine was orginally written by Linjiong Zhou


"rouine" should be "routine"

climbfuji · 2021-06-04T19:28:34Z

physics/mp_thompson.F90

@@ -439,6 +448,12 @@ subroutine mp_thompson_run(ncol, nlev, con_g, con_rd,        &
            return
         end if

+         dp1 = del! ! moist air mass * grav
+         dp0 = dp1


dp0 is not necessary - why not use del directly?

removed dp0 and del is used.

climbfuji · 2021-06-04T19:29:02Z

physics/mp_thompson.F90

@@ -439,6 +448,12 @@ subroutine mp_thompson_run(ncol, nlev, con_g, con_rd,        &
            return
         end if

+         dp1 = del! ! moist air mass * grav


This line is not necessary. Line 453 could be dp1 = del*...

yangfanglin · 2021-06-04T19:59:18Z

The FV3 dycore option used for GFS is positive definite. It has been known that in the GFS convection and the PBL schemes tend to produce negative tracers. There are plans to fix them. It is still not clear if Thompson MP itself produces negative tracers. Global mean precipitable water keeps increasing if negative tracers are reset to zero in Thompson MP. This issue needs to be fixed for MRW/S2S and climate applications. -- Fanglin

…

On Fri, Jun 4, 2021 at 3:42 PM gthompsnWRF ***@***.***> wrote: ***@***.***WRF* commented on this pull request. ------------------------------ In physics/module_mp_thompson.F90 <#619 (comment)>: > @@ -1275,6 +1281,11 @@ SUBROUTINE mp_gt_driver(qv, qc, qr, qi, qs, qg, ni, nr, nc, & enddo endif + if(ffixneg) then It is not clear to me why this negative adjustment is done here. Since it is before the actual call to Thompson microphysics, it looks more like a "sanitize whatever the model produces before calling Thompson MP" step. If really necessary shouldn't this be done outside/before the/any microphysics scheme? I can at least answer that resetting negative MP variables to zero is something found in my existing code - and is found in other WRF microphysics schemes as well. However, elevating something like ensuring non-negative values to a place above/before any calls to any MP-scheme seems like a step for someone to consider. These negative values are presumed to come from non-positive-definite advection schemes and really aren't related to microphysics schemes themselves. And, yet, to protect against bad data, this is a necessary step in the past in WRF because users can choose from a menu of advection options, some of which are not positive-definite. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2LEJPUHPRZEJXEUQ6DTREUBZANCNFSM42ZT6TDQ> .

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

gthompsnWRF · 2021-06-04T20:17:46Z

The FV3 dycore option used for GFS is positive definite. It has been known that in the GFS convection and the PBL schemes tend to produce negative tracers. There are plans to fix them. It is still not clear if Thompson MP itself produces negative tracers. Global mean precipitable water keeps increasing if negative tracers are reset to zero in Thompson MP. This issue needs to be fixed for MRW/S2S and climate applications. -- Fanglin

Thank you for that valued comment. At least in my very long time using WRF, there has never been a negative MP species put out by the Thompson microphysics schemes. There are a number of protections against that designed into the code. The fact that either convection or PBL schemes are giving negative values produces high levels of concerns to me. And Dom said that Joe is trying to diagnose potential cause(s) which would be good.

climbfuji · 2021-07-22T15:15:50Z

@gthompsnWRF @RuiyuSun This "constraints" PR has been on hold for weeks, and several new developments were made in the meantime (inner loop, subcycling). @gthompsnWRF and @ericaligo-NOAA are also working on identifying the few processes that contribute to the large heating rates and treat them differently (e.g. by reducing the time step just for them).

Is my understanding correct that this "constraints" PR is no longer an option and can be closed?

yangfanglin · 2021-07-22T15:38:18Z

My recommendation is to close this PR. Fanglin

…

On Thu, Jul 22, 2021 at 11:16 AM Dom Heinzeller ***@***.***> wrote: @gthompsnWRF <https://github.com/gthompsnWRF> @RuiyuSun <https://github.com/RuiyuSun> This "constraints" PR has been on hold for weeks, and several new developments were made in the meantime (inner loop, subcycling). @gthompsnWRF <https://github.com/gthompsnWRF> and @ericaligo-NOAA <https://github.com/ericaligo-NOAA> are also working on identifying the few processes that contribute to the large heating rates and treat them differently (e.g. by reducing the time step just for them). Is my understanding correct that this "constraints" PR is no longer an option and can be closed? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2J7BIHQCGR64KJQALDTZAY3FANCNFSM42ZT6TDQ> .

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

RuiyuSun · 2021-07-22T17:27:15Z

OK. Agreed. Ruiyu On Thu, Jul 22, 2021 at 11:38 AM Fanglin Yang ***@***.***> wrote:

…

My recommendation is to close this PR. Fanglin On Thu, Jul 22, 2021 at 11:16 AM Dom Heinzeller ***@***.***> wrote: > @gthompsnWRF <https://github.com/gthompsnWRF> @RuiyuSun > <https://github.com/RuiyuSun> This "constraints" PR has been on hold for > weeks, and several new developments were made in the meantime (inner loop, > subcycling). @gthompsnWRF <https://github.com/gthompsnWRF> and > @ericaligo-NOAA <https://github.com/ericaligo-NOAA> are also working on > identifying the few processes that contribute to the large heating rates > and treat them differently (e.g. by reducing the time step just for them). > > Is my understanding correct that this "constraints" PR is no longer an > option and can be closed? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#619 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AKY5N2J7BIHQCGR64KJQALDTZAY3FANCNFSM42ZT6TDQ > > . > -- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFOCLEN3UZATL6TH4DWBUDTZA3PJANCNFSM42ZT6TDQ> .

-- Ruiyu Sun, PhD *IMSG* at NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2097 College Park, MD 20740 ***@***.*** ***@***.***> 301-683-3787

climbfuji · 2021-07-22T17:43:47Z

Closing as agreed upon.

* Changes to typedefs for RRTMGP refactoring. Updates to prebuild and SDFs. * bugfix to save q state regardless of diagnostic flag, submodule update * optimizing massflux at cloud base based on P8 simulations, submodule update ccpp/physics * Added RRTMGP p8 coupled RT. * Move allocation of RRTMGP DDTs to init. * Removed deprecated SDFs Co-authored-by: Lisa Bengtsson <Lisa.Bengtsson@noaa.gov>

add constraints and namelist for Thompson MP

e961e7d

RuiyuSun requested review from climbfuji, grantfirl, JulieSchramm and llpcarson as code owners April 12, 2021 16:26

replace 273.16 with T_0 in neg_adj routine

d34cde5

climbfuji requested changes Apr 19, 2021

View reviewed changes

climbfuji linked an issue Apr 19, 2021 that may be closed by this pull request

Adding constraints and namelist options to the Thompson MP #618

Closed

climbfuji changed the title ~~add constraints and namelist variables for Thompson MP~~ Add constraints and namelist variables for Thompson MP Apr 22, 2021

RuiyuSun mentioned this pull request Apr 23, 2021

Constraints ufs-community/ufs-weather-model#518

Closed

13 tasks

climbfuji added do not merge work in progress labels May 10, 2021

Merge branch 'master' into constraints

b5a3156

climbfuji removed the do not merge label May 27, 2021

climbfuji requested a review from gthompsnWRF June 3, 2021 21:59

gthompsnWRF requested changes Jun 4, 2021

View reviewed changes

climbfuji requested changes Jun 4, 2021

View reviewed changes

climbfuji added wontfix and removed work in progress labels Jul 22, 2021

climbfuji closed this Jul 22, 2021

Add constraints and namelist variables for Thompson MP #619

Add constraints and namelist variables for Thompson MP #619

Conversation

RuiyuSun commented Apr 12, 2021 • edited by climbfuji Loading

climbfuji commented Apr 14, 2021

climbfuji left a comment

Choose a reason for hiding this comment

RuiyuSun commented Apr 19, 2021 via email

climbfuji commented Apr 19, 2021

ligiabernardet commented May 7, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

climbfuji left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yangfanglin commented Jun 4, 2021 via email

gthompsnWRF commented Jun 4, 2021 • edited Loading

climbfuji commented Jul 22, 2021

yangfanglin commented Jul 22, 2021 via email

RuiyuSun commented Jul 22, 2021 via email

climbfuji commented Jul 22, 2021

RuiyuSun commented Apr 12, 2021 •

edited by climbfuji

Loading

gthompsnWRF commented Jun 4, 2021 •

edited

Loading