Precipitation rates for NoahMP are likely being calculated in the wrong place

[grantfirl]

NoahMP expects precipitation rates and calculates its own from Diag% variables immediately prior to being called. This is problematic because Diag% variables get zeroed out before physics is called periodically such that the precipitation rates NoahMP sees will periodically be zero. For the initial CCPP transition, this calculation was done in a sfc_noahmp_pre interstitial routine to achieve bit-for-bit with the non-CCPP version. These rates should be calculated the previous time step in GFS_MP_generic_post (like what is done for RUC LSM) and put into a persistent variable rather than the Diag% DDT.

[climbfuji]

@junwang-noaa @DusanJovic-NOAA @HelinWei-NOAA - are you aware of this? Can you double check? Making the proposed changes will change the answer. Thanks.

[HelinWei-NOAA]

Hi Dom, I am not aware of that issue? Can you give me more detail? Thanks. Helin

…

On Nov 18, 2019, at 1:39 PM, Dom Heinzeller ***@***.***> wrote:  @junwang-noaa @DusanJovic-NOAA @HelinWei-NOAA - are you aware of this? Can you double check? Making the proposed changes will change the answer. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[HelinWei-NOAA]

The results from Noah mp so far always seem too dry (too little evaporation). Hope this bias has something to do with this bug

…

Sent from my iPhone

On Nov 18, 2019, at 1:39 PM, Dom Heinzeller ***@***.***> wrote:  @junwang-noaa @DusanJovic-NOAA @HelinWei-NOAA - are you aware of this? Can you double check? Making the proposed changes will change the answer. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[climbfuji]

@grantfirl reported this, I defer to him for further details. But I know that for RUC LSM, we added additional variables to preserve the precipitation rates, since RUC LSM also needs this information.

[grantfirl]

Hi Dom, I am not aware of that issue? Can you give me more detail? Thanks. Helin
…
On Nov 18, 2019, at 1:39 PM, Dom Heinzeller @.***> wrote:  @junwang-noaa @DusanJovic-NOAA @HelinWei-NOAA - are you aware of this? Can you double check? Making the proposed changes will change the answer. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Hi Helin,

I came across this potential bug when transitioning NoahMP into the CCPP. Here is my understanding of the issue. If you look in GFS_physics_driver.F90, search for the rainn_mp variable for example. When NoahMP is used, this variable (and similar variables for other precip. species) is calculated using variables in the "Diag" GFS derived data type (DDT). I think that the variables in this DDT are used to accumulate diagnostics for averaging over some periodicity and are zeroed out after calculating their time-averaged values periodically prior to physics being called. I have not actually run any tests to show that this actually happens, but I would suspect that this causes NoahMP to be given zero values for precipitation rates immediately after diagnostics have been written out and zeroed.

To get around this, rather than calculating precipitation rates for NoahMP from variables in the Diag DDT before the call to NoahMP, I think that it would work to follow what was done for the RUC LSM, like Dom mentioned. For that scheme, they save surface precipitation values immediately after microphysics is called into one of the DDTs that does not get zeroed or reinitialized every time step (they chose to use the Tbd DDT, but the decision is somewhat arbitrary). In the CCPP, the file GFS_MP_generic.F90 is the interstitial scheme that gets called after any microphysics scheme, and you can see a code stanza around lines 184-192 where this is done. They're saving liquid water equivalent thickness values, and NoahMP needs rates, but one could execute those same lines for when lsm==lsm_noahmp. Then, in the sfc_noahmp_pre_run scheme in the CCPP, one could convert the thicknesses into rates for use in NoahMP.

-Grant

[HelinWei-NOAA]

Hi Grant, Thank for finding out this potential bug. If this is the case, that will be also a problem for Noah. Because we also use some of those variables in the "Diag" GFS derived data type (DDT) to calculate srflag to pass into Noah LSM. I am going to take a further look and have some tests. Helin

…

On Mon, Nov 18, 2019 at 3:40 PM grantfirl ***@***.***> wrote: Hi Dom, I am not aware of that issue? Can you give me more detail? Thanks. Helin … <#m_8914092979223549424_m_-2162555601173180407_> On Nov 18, 2019, at 1:39 PM, Dom Heinzeller *@*.***> wrote:  @junwang-noaa <https://github.com/junwang-noaa> @DusanJovic-NOAA <https://github.com/DusanJovic-NOAA> @HelinWei-NOAA <https://github.com/HelinWei-NOAA> - are you aware of this? Can you double check? Making the proposed changes will change the answer. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Hi Helin, I came across this potential bug when transitioning NoahMP into the CCPP. Here is my understanding of the issue. If you look in GFS_physics_driver.F90, search for the rainn_mp variable for example. When NoahMP is used, this variable (and similar variables for other precip. species) is calculated using variables in the "Diag" GFS derived data type (DDT). I think that the variables in this DDT are used to accumulate diagnostics for averaging over some periodicity and are zeroed out after calculating their time-averaged values periodically prior to physics being called. I have not actually run any tests to show that this actually happens, but I would suspect that this causes NoahMP to be given zero values for precipitation rates immediately after diagnostics have been written out and zeroed. To get around this, rather than calculating precipitation rates for NoahMP from variables in the Diag DDT before the call to NoahMP, I think that it would work to follow what was done for the RUC LSM, like Dom mentioned. For that scheme, they save surface precipitation values immediately after microphysics is called into one of the DDTs that does not get zeroed or reinitialized every time step (they chose to use the Tbd DDT, but the decision is somewhat arbitrary). In the CCPP, the file GFS_MP_generic.F90 is the interstitial scheme that gets called after any microphysics scheme, and you can see a code stanza around lines 184-192 where this is done. They're saving liquid water equivalent thickness values, and NoahMP needs rates, but one could execute those same lines for when lsm==lsm_noahmp. Then, in the sfc_noahmp_pre_run scheme in the CCPP, one could convert the thicknesses into rates for use in NoahMP. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319?email_source=notifications&email_token=ALPHKYERT3O6MDVMLO7OUBLQUL4SHA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL2VQA#issuecomment-555199168>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPHKYAN4XJ2YCJ3NUCVV6DQUL4SHANCNFSM4IWVDJSA> .

[HelinWei-NOAA]

Hi Grant, I prefer to add these four variables to Sfcprop DDT. In this way both Noah MP and RUC can share them. What do you think? There should be no impact on Noah because srflag is calculated after MP in the same subroutine, nulike Noah MP driver is called before MP. Helin On Mon, Nov 18, 2019 at 4:07 PM Helin Wei - NOAA Affiliate < [email protected]> wrote:

…

Hi Grant, Thank for finding out this potential bug. If this is the case, that will be also a problem for Noah. Because we also use some of those variables in the "Diag" GFS derived data type (DDT) to calculate srflag to pass into Noah LSM. I am going to take a further look and have some tests. Helin On Mon, Nov 18, 2019 at 3:40 PM grantfirl ***@***.***> wrote: > Hi Dom, I am not aware of that issue? Can you give me more detail? > Thanks. Helin > … <#m_-7065188098019345833_m_8914092979223549424_m_-2162555601173180407_> > On Nov 18, 2019, at 1:39 PM, Dom Heinzeller *@*.***> wrote:  > @junwang-noaa <https://github.com/junwang-noaa> @DusanJovic-NOAA > <https://github.com/DusanJovic-NOAA> @HelinWei-NOAA > <https://github.com/HelinWei-NOAA> - are you aware of this? Can you > double check? Making the proposed changes will change the answer. Thanks. — > You are receiving this because you were mentioned. Reply to this email > directly, view it on GitHub, or unsubscribe. > > Hi Helin, > > I came across this potential bug when transitioning NoahMP into the CCPP. > Here is my understanding of the issue. If you look in > GFS_physics_driver.F90, search for the rainn_mp variable for example. When > NoahMP is used, this variable (and similar variables for other precip. > species) is calculated using variables in the "Diag" GFS derived data type > (DDT). I think that the variables in this DDT are used to accumulate > diagnostics for averaging over some periodicity and are zeroed out after > calculating their time-averaged values periodically prior to physics being > called. I have not actually run any tests to show that this actually > happens, but I would suspect that this causes NoahMP to be given zero > values for precipitation rates immediately after diagnostics have been > written out and zeroed. > > To get around this, rather than calculating precipitation rates for > NoahMP from variables in the Diag DDT before the call to NoahMP, I think > that it would work to follow what was done for the RUC LSM, like Dom > mentioned. For that scheme, they save surface precipitation values > immediately after microphysics is called into one of the DDTs that does not > get zeroed or reinitialized every time step (they chose to use the Tbd DDT, > but the decision is somewhat arbitrary). In the CCPP, the file > GFS_MP_generic.F90 is the interstitial scheme that gets called after any > microphysics scheme, and you can see a code stanza around lines 184-192 > where this is done. They're saving liquid water equivalent thickness > values, and NoahMP needs rates, but one could execute those same lines for > when lsm==lsm_noahmp. Then, in the sfc_noahmp_pre_run scheme in the CCPP, > one could convert the thicknesses into rates for use in NoahMP. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#319?email_source=notifications&email_token=ALPHKYERT3O6MDVMLO7OUBLQUL4SHA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL2VQA#issuecomment-555199168>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ALPHKYAN4XJ2YCJ3NUCVV6DQUL4SHANCNFSM4IWVDJSA> > . >

[climbfuji]

Hi Helin, I think this is just fine (from my side, don't want to speak for Grant). Should we make those changes in our dtc/develop branches and bring them to the master code with our next merge? Good to see that NoahMP and RUC can share those variables. Thanks for investigating the issue!

[HelinWei-NOAA]

Hi Dom, I think we should. I am going to have some tests with this fix and talk to Jun when she is back to office next week. Thanks. Helin

…

On Mon, Nov 18, 2019 at 10:20 PM Dom Heinzeller ***@***.***> wrote: Hi Helin, I think this is just fine (from my side, don't want to speak for Grant). Should we make those changes in our dtc/develop branches and bring them to the master code with our next merge? Good to see that NoahMP and RUC can share those variables. Thanks for investigating the issue! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319?email_source=notifications&email_token=ALPHKYGXVXMXU3LBTLZWVDLQUNLPBA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEMW2AY#issuecomment-555314435>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPHKYE7B7EUHKVV7VHP2YTQUNLPBANCNFSM4IWVDJSA> .

[grantfirl]

Hi Grant, I prefer to add these four variables to Sfcprop DDT. In this way both Noah MP and RUC can share them. What do you think? There should be no impact on Noah because srflag is calculated after MP in the same subroutine, nulike Noah MP driver is called before MP. Helin On Mon, Nov 18, 2019 at 4:07 PM Helin Wei - NOAA Affiliate < [email protected]> wrote:
…
Hi Grant, Thank for finding out this potential bug. If this is the case, that will be also a problem for Noah. Because we also use some of those variables in the "Diag" GFS derived data type (DDT) to calculate srflag to pass into Noah LSM. I am going to take a further look and have some tests. Helin On Mon, Nov 18, 2019 at 3:40 PM grantfirl @.> wrote: > Hi Dom, I am not aware of that issue? Can you give me more detail? > Thanks. Helin > … <#m_-7065188098019345833_m_8914092979223549424_m_-2162555601173180407_> > On Nov 18, 2019, at 1:39 PM, Dom Heinzeller @.> wrote:  > @junwang-noaa https://github.com/junwang-noaa @DusanJovic-NOAA > https://github.com/DusanJovic-NOAA @HelinWei-NOAA > https://github.com/HelinWei-NOAA - are you aware of this? Can you > double check? Making the proposed changes will change the answer. Thanks. — > You are receiving this because you were mentioned. Reply to this email > directly, view it on GitHub, or unsubscribe. > > Hi Helin, > > I came across this potential bug when transitioning NoahMP into the CCPP. > Here is my understanding of the issue. If you look in > GFS_physics_driver.F90, search for the rainn_mp variable for example. When > NoahMP is used, this variable (and similar variables for other precip. > species) is calculated using variables in the "Diag" GFS derived data type > (DDT). I think that the variables in this DDT are used to accumulate > diagnostics for averaging over some periodicity and are zeroed out after > calculating their time-averaged values periodically prior to physics being > called. I have not actually run any tests to show that this actually > happens, but I would suspect that this causes NoahMP to be given zero > values for precipitation rates immediately after diagnostics have been > written out and zeroed. > > To get around this, rather than calculating precipitation rates for > NoahMP from variables in the Diag DDT before the call to NoahMP, I think > that it would work to follow what was done for the RUC LSM, like Dom > mentioned. For that scheme, they save surface precipitation values > immediately after microphysics is called into one of the DDTs that does not > get zeroed or reinitialized every time step (they chose to use the Tbd DDT, > but the decision is somewhat arbitrary). In the CCPP, the file > GFS_MP_generic.F90 is the interstitial scheme that gets called after any > microphysics scheme, and you can see a code stanza around lines 184-192 > where this is done. They're saving liquid water equivalent thickness > values, and NoahMP needs rates, but one could execute those same lines for > when lsm==lsm_noahmp. Then, in the sfc_noahmp_pre_run scheme in the CCPP, > one could convert the thicknesses into rates for use in NoahMP. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#319?email_source=notifications&email_token=ALPHKYERT3O6MDVMLO7OUBLQUL4SHA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL2VQA#issuecomment-555199168>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/ALPHKYAN4XJ2YCJ3NUCVV6DQUL4SHANCNFSM4IWVDJSA > . >

Hi Helin,

I think that this is fine too. Just to confirm, you are planning on making these code changes and testing them? If not, let Dom and I know, and we'll make the changes as described and submit a pull request for you to approve.

If in fact NoahMP was seeing zero precipitation rates periodically, the modified code will definitely not pass the existing NoahMP regression test and will require a new baseline.

-Grant

[HelinWei-NOAA]

Hi Grant, I have some difficulties to access WCOSS due to the network issue. It would be great if you and Dom can make the corresponding change. So if we put those 5 variables into Sfcprop DDT like the way we handle Sfcprop%tprcp, they will be part of restart file and we need to coldstar them. What's the strategy should we use? Assigning all precip to snow if Ts is below freezing? If it is rain, half goes to convective and half goes to non-convective? We can coldstart graupel and ice as 0. Thanks. Helin

…

On Tue, Nov 19, 2019 at 11:28 AM grantfirl ***@***.***> wrote: Hi Grant, I prefer to add these four variables to Sfcprop DDT. In this way both Noah MP and RUC can share them. What do you think? There should be no impact on Noah because srflag is calculated after MP in the same subroutine, nulike Noah MP driver is called before MP. Helin On Mon, Nov 18, 2019 at 4:07 PM Helin Wei - NOAA Affiliate < ***@***.***> wrote: … <#m_3620999979588939310_> Hi Grant, Thank for finding out this potential bug. If this is the case, that will be also a problem for Noah. Because we also use some of those variables in the "Diag" GFS derived data type (DDT) to calculate srflag to pass into Noah LSM. I am going to take a further look and have some tests. Helin On Mon, Nov 18, 2019 at 3:40 PM grantfirl *@*.*> wrote: > Hi Dom, I am not aware of that issue? Can you give me more detail? > Thanks. Helin > … <#m_-7065188098019345833_m_8914092979223549424_m_-2162555601173180407_> > On Nov 18, 2019, at 1:39 PM, Dom Heinzeller @.*> wrote:  > @junwang-noaa <https://github.com/junwang-noaa> https://github.com/junwang-noaa @DusanJovic-NOAA <https://github.com/DusanJovic-NOAA> > https://github.com/DusanJovic-NOAA @HelinWei-NOAA <https://github.com/HelinWei-NOAA> > https://github.com/HelinWei-NOAA - are you aware of this? Can you > double check? Making the proposed changes will change the answer. Thanks. — > You are receiving this because you were mentioned. Reply to this email > directly, view it on GitHub, or unsubscribe. > > Hi Helin, > > I came across this potential bug when transitioning NoahMP into the CCPP. > Here is my understanding of the issue. If you look in > GFS_physics_driver.F90, search for the rainn_mp variable for example. When > NoahMP is used, this variable (and similar variables for other precip. > species) is calculated using variables in the "Diag" GFS derived data type > (DDT). I think that the variables in this DDT are used to accumulate > diagnostics for averaging over some periodicity and are zeroed out after > calculating their time-averaged values periodically prior to physics being > called. I have not actually run any tests to show that this actually > happens, but I would suspect that this causes NoahMP to be given zero > values for precipitation rates immediately after diagnostics have been > written out and zeroed. > > To get around this, rather than calculating precipitation rates for > NoahMP from variables in the Diag DDT before the call to NoahMP, I think > that it would work to follow what was done for the RUC LSM, like Dom > mentioned. For that scheme, they save surface precipitation values > immediately after microphysics is called into one of the DDTs that does not > get zeroed or reinitialized every time step (they chose to use the Tbd DDT, > but the decision is somewhat arbitrary). In the CCPP, the file > GFS_MP_generic.F90 is the interstitial scheme that gets called after any > microphysics scheme, and you can see a code stanza around lines 184-192 > where this is done. They're saving liquid water equivalent thickness > values, and NoahMP needs rates, but one could execute those same lines for > when lsm==lsm_noahmp. Then, in the sfc_noahmp_pre_run scheme in the CCPP, > one could convert the thicknesses into rates for use in NoahMP. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#319 <#319>?email_source=notifications&email_token=ALPHKYERT3O6MDVMLO7OUBLQUL4SHA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL2VQA#issuecomment-555199168>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/ALPHKYAN4XJ2YCJ3NUCVV6DQUL4SHANCNFSM4IWVDJSA > . > Hi Helin, I think that this is fine too. Just to confirm, you are planning on making these code changes and testing them? If not, let Dom and I know, and we'll make the changes as described and submit a pull request for you to approve. If in fact NoahMP was seeing zero precipitation rates periodically, the modified code will definitely not pass the existing NoahMP regression test and will require a new baseline. -Grant — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319?email_source=notifications&email_token=ALPHKYENPAZO5I5X56JA7BDQUQHZ7A5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEO2BAA#issuecomment-555589760>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPHKYCKHAH2DV3D7FZBA3LQUQHZ7ANCNFSM4IWVDJSA> .

[climbfuji]

Helin, it doesn't matter where the variables are stored, both Sfcprop and Tbd can be written to restart files. Currently we have for RUC in GFS_restart.F90:

    if (Model%lsm == Model%lsm_ruc) then
      num = num + 1
      Restart%name2d(num) = 'ruc_2d_raincprv'
      do nb = 1,nblks
        Restart%data(nb,num)%var2p => Tbd(nb)%raincprv(:)
      enddo
      num = num + 1
      Restart%name2d(num) = 'ruc_2d_rainncprv'
      do nb = 1,nblks
        Restart%data(nb,num)%var2p => Tbd(nb)%rainncprv(:)
      enddo
      num = num + 1
      Restart%name2d(num) = 'ruc_2d_iceprv'
      do nb = 1,nblks
        Restart%data(nb,num)%var2p => Tbd(nb)%iceprv(:)
      enddo
      num = num + 1
      Restart%name2d(num) = 'ruc_2d_snowprv'
      do nb = 1,nblks
        Restart%data(nb,num)%var2p => Tbd(nb)%snowprv(:)
      enddo
      num = num + 1
      Restart%name2d(num) = 'ruc_2d_graupelprv'
      do nb = 1,nblks
        Restart%data(nb,num)%var2p => Tbd(nb)%graupelprv(:)
      enddo
    endif

Regarding your question about coldstarting them. For RUC I believe the first timestep of the coldstart run will just contain zeros for all those fields. I would like to bring @tanyasmirnova into the discussion, since Tanya is the expert on RUC and RUC in FV3.

[climbfuji]

Where are we at with this? Who is supposed to take action and make the changes? Seems to be a rather important fix to me. Thanks.

[HelinWei-NOAA]

Hi Dom, Since we use the precip rate instead of accumulation, they will not be zero out at bucket interval. I am still looking for if they get re-initialized when passing from MP to LSM. Jun is the most familiar with the whole structure but she is out of town. Do you happen to know any place those variables get re-initialized? LSM is called before MP in the physics driver. The re-initialization should be fine after LSM and before MP. Thanks. Helin

…

On Wed, Nov 20, 2019 at 12:17 PM Dom Heinzeller ***@***.***> wrote: Where are we at with this? Who is supposed to take action and make the changes? Seems to be a rather important fix to me. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319?email_source=notifications&email_token=ALPHKYCWW5HJHXZRF4PZTYDQUVWLLA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEES45KY#issuecomment-556125867>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPHKYBTP4AIOOC64HNLYCLQUVWLLANCNFSM4IWVDJSA> .

[grantfirl]

@HelinWei-NOAA
The following pull requests address this issue:
NCAR/fv3atm#14
#365

The precipitation rates needed by NoahMP are now calculated after the microphysics call in preparation for the following timestep of NoahMP. They have also been put in the Sfcprop DDT.

I do not have any tests that show the difference, but from code inspection, when the precipitation rates were calculated prior to the NoahMP call using Diag%rain,rainc,ice,snow,graupel, it definitely looks to me like they would end up at zero after the diagnostics have been written out. In GFS_driver.F90, there are periodic calls to Diag%phys_zero that get executed before the call to physics. This subroutine is defined in GFS_typedefs.F90 as diag_phys_zero. All five of these variables are set to zero inside. This same functionality is mimicked in the CCPP via "time_vary" interstitial schemes.

Please have a look at the pull requests when you get a chance to see if you agree with the changes. Even if there is no or minimal difference, I don't think that these changes "do any harm" from a coding point of view, and would at least provide consistency with how the RUC LSM operates.

[HelinWei-NOAA]

Grant and Dom, Thanks. We agree there are some issues for the way to deal precip in GFS_physics_driver.F90. Diag%rain,rainc,ice,snow,graupel should be in the unit of precip rate. They should not do any accumulation and be zeroed out. However Diag%rain,rainc did get accumulated in GFS_physics_driver.F90 and zeroed out in diag_phys_zero with the other three types (ice,snow,graupel). We should sort this out sooner rather than later. Sfcprop%tprcp is treated as total precip rate in all physics. However it is assigned to Diag%rain, which got accumulated mistakenly. So if my understanding is correct, this is a bug for all physics. Best, Helin

…

On Fri, Dec 6, 2019 at 11:32 AM grantfirl ***@***.***> wrote: @HelinWei-NOAA <https://github.com/HelinWei-NOAA> The following pull requests address this issue: NCAR/fv3atm#14 <NCAR/fv3atm#14> #365 <#365> The precipitation rates needed by NoahMP are now calculated after the microphysics call in preparation for the following timestep of NoahMP. They have also been put in the Sfcprop DDT. I do not have any tests that show the difference, but from code inspection, when the precipitation rates were calculated prior to the NoahMP call using Diag%rain,rainc,ice,snow,graupel, it definitely looks to me like they would end up at zero after the diagnostics have been written out. In GFS_driver.F90, there are periodic calls to Diag%phys_zero that get executed before the call to physics. This subroutine is defined in GFS_typedefs.F90 as diag_phys_zero. All five of these variables are set to zero inside. This same functionality is mimicked in the CCPP via "time_vary" interstitial schemes. Please have a look at the pull requests when you get a chance to see if you agree with the changes. Even if there is no or minimal difference, I don't think that these changes "do any harm" from a coding point of view, and would at least provide consistency with how the RUC LSM operates. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#319?email_source=notifications&email_token=ALPHKYE6YAIIODTA4UC6OI3QXJ5ANA5CNFSM4IWVDJSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGEUEDQ#issuecomment-562643470>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPHKYGSV4HFH3AEDMGOUTLQXJ5ANANCNFSM4IWVDJSA> .

[climbfuji]

Fixed in #365 and PRs referenced there. 10-day forecasts with the old and new version will be made to check the differences.