Merge cnvc90 into existing interstitial scheme

[climbfuji]

According to @grantfirl, CCPP scheme cnvc90 can be removed for 2 reasons:

• the namelist variable that turns it on is never modified from the default (-9999)
• the output variables from the scheme are diagnostic and not used by any other CCPP scheme

[SMoorthi-emc]

Dom, Please contact the EMC physics group leader regarding this. The output from this routine is still used in the operational GFS output as far I know.

[yangfanglin]

Jongil,

Could you please check and confirm.

Thanks Fanglin

On Mon, Apr 5, 2021 at 12:50 PM SMoorthi-emc @.***> wrote:

Dom, Please contact the EMC physics group leader regarding this. The output from this routine is still used in the operational GFS output as far I know.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813499002, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKY5N2OUMZ7WZCCJTXQYIKLTHHS5JANCNFSM42NCNKBA .

-- 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/

[SMoorthi-emc]

CV, CVb and CVt are used in the ncep_post as operational products, Thus I don't think we can remove this code at this time.

On Mon, Apr 5, 2021 at 1:01 PM Fanglin Yang @.***> wrote:

Jongil,

Could you please check and confirm.

Thanks Fanglin

On Mon, Apr 5, 2021 at 12:50 PM SMoorthi-emc @.***> wrote:

Dom, Please contact the EMC physics group leader regarding this. The output from this routine is still used in the operational GFS output as far I know.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813499002 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AKY5N2OUMZ7WZCCJTXQYIKLTHHS5JANCNFSM42NCNKBA

.

-- 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 assigned. Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813505372, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALLVRYT7FJKE4GATZK6JO73THHUG3ANCNFSM42NCNKBA .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718

e-mail: @.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[climbfuji]

CV, CVb and CVt are used in the ncep_post as operational products, Thus I don't think we can remove this code at this time. On Mon, Apr 5, 2021 at 1:01 PM Fanglin Yang @.***> wrote: …

Thank you, Moorthi. Good to know. So the operational version does set the parameter differently that controls whether cnvc90 is on or off?

[SMoorthi-emc]

I am not 100% sure, but it is indeed passed to the output through "GFS_diagnostics.F90".

On Mon, Apr 5, 2021 at 1:50 PM Dom Heinzeller @.***> wrote:

CV, CVb and CVt are used in the ncep_post as operational products, Thus I don't think we can remove this code at this time. On Mon, Apr 5, 2021 at 1:01 PM Fanglin Yang @.***> wrote: … <#m_6128747551302283139_>

Thank you, Moorthi. Good to know. So the operational version does set the parameter differently that controls whether cnvc90 is on or off?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813534305, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALLVRYRZG2WDYTROHMCLKG3THHZ6ZANCNFSM42NCNKBA .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718

e-mail: @.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[yangfanglin]

This is a very old program, probably written by Ken Campana or Yutai. Unfortunately, there are still users of CV, CVb and CVt. No matter which convection scheme is used, these variables need to be kept for operation.

On Mon, Apr 5, 2021 at 1:53 PM SMoorthi-emc @.***> wrote:

I am not 100% sure, but it is indeed passed to the output through "GFS_diagnostics.F90".

On Mon, Apr 5, 2021 at 1:50 PM Dom Heinzeller @.***> wrote:

CV, CVb and CVt are used in the ncep_post as operational products, Thus I don't think we can remove this code at this time. On Mon, Apr 5, 2021 at 1:01 PM Fanglin Yang @.***> wrote: … <#m_6128747551302283139_>

Thank you, Moorthi. Good to know. So the operational version does set the parameter differently that controls whether cnvc90 is on or off?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813534305 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ALLVRYRZG2WDYTROHMCLKG3THHZ6ZANCNFSM42NCNKBA

.

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718

e-mail: @.*** Phone: (301) 683-3718 Fax: (301) 683-3718

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813535633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKY5N2ITNEFPIXAQ3EMFTV3THH2HVANCNFSM42NCNKBA .

-- 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/

[grantfirl]

@climbfuji Plus, the statement "the namelist variable that turns it on is never modified from the default (-9999)" is actually in error. It looks like in the timestep_init phase of GFS_phys_time_vary, the control variable (clstp) is set, and if it ever was controlled by namelist, it doesn't appear to be now. So, I don't actually remember ever bringing this up, but it definitely appears that I was in error.

Since the cnvc90 "scheme" is only calculating convective-based diagnostics, if the impetus behind the issue is to try to simplify the GFS-based suite-definition files, would it make sense for another GFS-based interstitial to "absorb" the functionality of cnvc90? It looks like it just needs to be executed after all convective schemes. Just a thought, not a recommendation.

Also, I can't remember why, but I had occasion to take notes on how the program works several months ago. Since there is virtually no documentation on what the program is doing, I could potentially add some in-line comments based on my notes if it would be helpful.

[climbfuji]

@climbfuji Plus, the statement "the namelist variable that turns it on is never modified from the default (-9999)" is actually in error. It looks like in the timestep_init phase of GFS_phys_time_vary, the control variable (clstp) is set, and if it ever was controlled by namelist, it doesn't appear to be now. So, I don't actually remember ever bringing this up, but it definitely appears that I was in error.

Since the cnvc90 "scheme" is only calculating convective-based diagnostics, if the impetus behind the issue is to try to simplify the GFS-based suite-definition files, would it make sense for another GFS-based interstitial to "absorb" the functionality of cnvc90? It looks like it just needs to be executed after all convective schemes. Just a thought, not a recommendation.

Also, I can't remember why, but I had occasion to take notes on how the program works several months ago. Since there is virtually no documentation on what the program is doing, I could potentially add some in-line comments based on my notes if it would be helpful.

Thanks, Grant. I was cleaning up my old emails and found one from you that I quoted in the description of this issue ;-)

Anyways, good that I checked. My take is that if this scheme is going to be around and its output used for much longer, we can merge it into one of the interstitial schemes. (I think GFS suite interstitial 4 runs after deep+shallow convection). If we expect it to go away soon, then I'd rather leave it where it is for now.

[yangfanglin]

Dom,

Removing products from operation takes a long time if there are no documented users. If there are still users of these variables we may not be able to remove them at all. At the least substitutes have to be provided. So "merge it into one of the interstitial schemes" is necessary.

Thanks Fanglin

On Mon, Apr 5, 2021 at 4:04 PM Dom Heinzeller @.***> wrote:

@climbfuji https://github.com/climbfuji Plus, the statement "the namelist variable that turns it on is never modified from the default (-9999)" is actually in error. It looks like in the timestep_init phase of GFS_phys_time_vary, the control variable (clstp) is set, and if it ever was controlled by namelist, it doesn't appear to be now. So, I don't actually remember ever bringing this up, but it definitely appears that I was in error.

Since the cnvc90 "scheme" is only calculating convective-based diagnostics, if the impetus behind the issue is to try to simplify the GFS-based suite-definition files, would it make sense for another GFS-based interstitial to "absorb" the functionality of cnvc90? It looks like it just needs to be executed after all convective schemes. Just a thought, not a recommendation.

Also, I can't remember why, but I had occasion to take notes on how the program works several months ago. Since there is virtually no documentation on what the program is doing, I could potentially add some in-line comments based on my notes if it would be helpful.

Thanks, Grant. I was cleaning up my old emails and found one from you that I quoted in the description of this issue ;-)

Anyways, good that I checked. My take is that if this scheme is going to be around and its output used for much longer, we can merge it into one of the interstitial schemes. (I think GFS suite interstitial 4 runs after deep+shallow convection). If we expect it to go away soon, then I'd rather leave it where it is for now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/issues/610#issuecomment-813618798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKY5N2MJGFJDWETB4RK6PGDTHIJWLANCNFSM42NCNKBA .

-- 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/

[climbfuji]

Ok, Fanglin, will do in the near future. Thanks all for your feedback.

[dustinswales]

@yangfanglin Sorry for the blast from the past... Are you okay with me moving cnvc90 from its own scheme into GFS_interstitial_4? (I have a cleanup PR in the works that. can add this to) Or should leave as is and move this issue over to discussions?

[yangfanglin]

@dustinswales Thanks for revisiting this issue. I am ok with you moving cnvc90 from its own scheme into GFS_interstitial_4. Based on the discussion the diagnostics/products will still be kept. Including @ChunxiZhang-NOAA for his awareness

[ChunxiZhang-NOAA]

@dustinswales @yangfanglin I am ok with that too. I would add if(imfshalcnv>0 .or. imfdeepcnv>0) condition for the code in the GFS_interstitial_4.