Merge cnvc90 into existing interstitial scheme #610
Comments
|
Dom, |
|
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
<#610 (comment)>,
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/>*
|
|
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
> <#610 (comment)
>,
> 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
<#610 (comment)>,
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
|
Thank you, Moorthi. Good to know. So the operational version does set the parameter differently that controls whether cnvc90 is on or off? |
|
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
<#610 (comment)>,
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
|
|
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
> <#610 (comment)
>,
> 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
<#610 (comment)>,
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/>*
|
|
@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. |
|
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
<#610 (comment)>,
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/>*
|
|
Ok, Fanglin, will do in the near future. Thanks all for your feedback. |
climbfuji
changed the title
|
@yangfanglin Sorry for the blast from the past... |
|
@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 |
|
@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. |
…#610) * Performance optimization of moving nest. * update atmos_model and FV3GFS_io read performance when io_layout=1,1 and allow one to override data integrity checks in FMS restart logic * Add the following HAFS ccpp physics suites (@ChunxiZhang-NOAA and @BinLiu-NOAA): suite_FV3_HAFS_v0_thompson.xml suite_FV3_HAFS_v0_thompson_nonsst.xml suite_FV3_HAFS_v0_thompson_noahmp.xml suite_FV3_HAFS_v0_thompson_noahmp_nonsst.xml * Update submodule UPP to point its latest develop branch as of 05/18/2022. * Update submodule upp, which has the fix for regional latlon grid crossing the prime meridian. * Only call atmosphere_fill_nest_cpl at the cap driver time steps (coupling time steps). This is to reduce the overhead introduced by downscaling the coupling variables from FV3ATM parent to nest. * Removed reference to unused variable parent_x. * FV3-related typedefs changes for the Hurricane PBL options * Update submodule ccpp/physics, which added the tc_pbl option in the GFS sa-TKE EDMF PBL scheme for HAFS/hurricane modeling. * Adding upoff as a namelist parameter * Update submodule atmos_cubed_sphere, which has updated the time string in internal tracker output (fort.602, phtcf file). * Restructure moving nest code from atmos_cubed_sphere into FV3 directory. * Rename HAFS_v0 CCPP physics suites to HAFS_V1. * Added namelist flag fv_timers to enable detailed performance timings; defaults to false. * Removed special CMake handling of moving nest files. This causes a switch from 'fp-model source' as they were compiled in atmos_cubed_sphere, to 'fp-model consistent' aligned with the FV3atm tree. Minor rounding differences are noted in forecast results. * Update submodule ccpp/physics and update tc_pbl standard and long names. * Removed ifdef MOVING_NEST, as files are included/excluded by cmake Co-authored-by: William Ramstrom <[email protected]> Co-authored-by: Rusty.Benson <[email protected]> Co-authored-by: AndrewHazelton <[email protected]> Co-authored-by: Biju Thomas <[email protected]>
According to @grantfirl, CCPP scheme
cnvc90can be removed for 2 reasons:The text was updated successfully, but these errors were encountered: