Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge cnvc90 into existing interstitial scheme #610

Open
climbfuji opened this issue Apr 5, 2021 · 13 comments
Open

Merge cnvc90 into existing interstitial scheme #610

climbfuji opened this issue Apr 5, 2021 · 13 comments
Assignees

Comments

@climbfuji
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

yangfanglin commented Apr 5, 2021 via email

@SMoorthi-emc
Copy link
Collaborator

SMoorthi-emc commented Apr 5, 2021 via email

@climbfuji
Copy link
Collaborator Author

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
Copy link
Collaborator

SMoorthi-emc commented Apr 5, 2021 via email

@yangfanglin
Copy link
Collaborator

yangfanglin commented Apr 5, 2021 via email

@grantfirl
Copy link
Collaborator

@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
Copy link
Collaborator Author

@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
Copy link
Collaborator

yangfanglin commented Apr 5, 2021 via email

@climbfuji
Copy link
Collaborator Author

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

@climbfuji climbfuji changed the title Remove cnvc90 scheme Merge cnvc90 into existing interstitial scheme May 14, 2021
@dustinswales
Copy link
Collaborator

@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
Copy link
Collaborator

@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
Copy link
Collaborator

@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.

HelinWei-NOAA pushed a commit to HelinWei-NOAA/ccpp-physics that referenced this issue Feb 26, 2023
…#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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants