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

[develop] Add option to change vertical coordinate file. #813

Merged
merged 3 commits into from Jun 12, 2023

Conversation

christinaholtNOAA
Copy link
Collaborator

DESCRIPTION OF CHANGES:

Add a configurable option for users to specify their own vertical coordinate file for the FV3 model. As an alternative to the current one, the RRFS version for 65 vertical levels has been added to parm.

The existing vertical coordinate definition file is managed as a fix file on various platforms. Should it be brought under version control under the parm directory so users can more easily compare/contrast the two files?

I added a new WE2E test that passes, but have not included it in any of the auto-tests. Guidance on when/where it should be run would be appreciated.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

TESTS CONDUCTED:

  • hera.intel
  • orion.intel
  • cheyenne.intel
  • cheyenne.gnu
  • gaea.intel
  • jet.intel
  • wcoss2.intel
  • NOAA Cloud (indicate which platform)
  • Jenkins
  • fundamental test suite
  • comprehensive tests (specify which if a subset was used)

The new test also passes for Hera/intel.

DEPENDENCIES:

None

DOCUMENTATION:

It could probably use some "how to change vertical levels" information here, but I don't know where or to what extend you want to document this besides just saying "here are two choices EPIC supports".

ISSUE:

Issue #576

CHECKLIST

  • My code follows the style guidelines in the Contributor's Guide
  • I have performed a self-review of my own code using the Code Reviewer's Guide
  • I have commented my code, particularly in hard-to-understand areas
  • My changes need updates to the documentation. I have made corresponding changes to the documentation
  • My changes do not require updates to the documentation (explain).
  • My changes generate no new warnings
  • New and existing tests pass with my changes
  • Any dependent changes have been merged and published

Copy link
Collaborator

@MichaelLueken MichaelLueken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@christinaholtNOAA The coverage, process_obs, and different_vcoord tests were run on Hera and all successfully passed. Approving this work now.

@christinaholtNOAA christinaholtNOAA self-assigned this May 30, 2023
Copy link
Collaborator

@mkavulich mkavulich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great step towards allowing for custom vertical coordinates, hope to see this full capability soon!

@MichaelLueken MichaelLueken added the run_we2e_coverage_tests Run the coverage set of SRW end-to-end tests label Jun 7, 2023
@MichaelLueken
Copy link
Collaborator

@christinaholtNOAA For this PR, the only failures were the expected failures on Gaea and Orion. Once manual run of the Jenkins tests on Orion are complete, I should be bale to merge this work.

@MichaelLueken
Copy link
Collaborator

@christinaholtNOAA The tests on Orion successfully passed:

----------------------------------------------------------------------------------------------------
Experiment name                                                  | Status    | Core hours used 
----------------------------------------------------------------------------------------------------
deactivate_tasks                                                   COMPLETE               1.17
get_from_AWS_ics_GEFS_lbcs_GEFS_fmt_grib2_2022040400_ensemble_2me  COMPLETE             769.23
grid_CONUS_3km_GFDLgrid_ics_FV3GFS_lbcs_FV3GFS_suite_RRFS_v1beta   COMPLETE             265.23
grid_RRFS_AK_13km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v16_plot        COMPLETE             143.45
grid_RRFS_CONUS_25km_ics_NAM_lbcs_NAM_suite_RRFS_v1beta            COMPLETE              16.77
grid_RRFS_CONUS_25km_ics_GSMGFS_lbcs_GSMGFS_suite_GFS_2017_gfdlmp  COMPLETE              10.02
grid_RRFS_CONUS_3km_ics_FV3GFS_lbcs_FV3GFS_suite_HRRR              COMPLETE             405.64
grid_RRFS_CONUScompact_13km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v16   COMPLETE              30.58
grid_RRFS_CONUScompact_3km_ics_FV3GFS_lbcs_FV3GFS_suite_GFS_v16    COMPLETE             284.08
grid_SUBCONUS_Ind_3km_ics_FV3GFS_lbcs_FV3GFS_suite_WoFS_v0         COMPLETE              14.13
nco                                                                COMPLETE               7.06
----------------------------------------------------------------------------------------------------
Total                                                              COMPLETE            1947.36

The existing vertical coordinate definition file is managed as a fix file on various platforms. Should it be brought under version control under the parm directory so users can more easily compare/contrast the two files?

It looks like both the L64 and L65 fix files are available on the Tier-1 platforms. However, the global_hyblev_fcst_rrfsL65.txt fix file isn't available in the SRW S3 bucket. Until this file is in the S3 bucket, I'm okay with keeping it in the parm directory. Since the L64 file is available in the S3 bucket, I think it would be best to keep it out of the parm directory. I'm certainly open to additional discussion on this (it is an ASCII file, so it wouldn't be an issue to add it to the parm directory).

I added a new WE2E test that passes, but have not included it in any of the auto-tests. Guidance on when/where it should be run would be appreciated.

Since the new vertical coordinate is for RRFS, would we want to include running this test with the process_obs test as part of the tests we run on the RRFS workflow PRs? The primary difference between process_obs and different_vcoord is that process_obs requires just the GSI and RRFS_utils to be built, while different_vcoord requires default flags. Further, since this work is currently for RRFS, it would probably be a good idea to ensure that it runs on either Hera, Jet, or both. If you would like, we can add this test to either coverage.hera.* or coverage.jet to ensure that this functionality isn't lost moving forward, or we can wait until the RRFS build is in place, then include the test as part of the RRFS build testing suite.

Since the tests have all passed, would you like for me to move forward with merging this work, or would you like for additional discussion within this PR? Please let me know how you would like to proceed.

@christinaholtNOAA
Copy link
Collaborator Author

@MichaelLueken Let's go ahead and move on merging this PR. I will work toward adding an additional RRFS build and test suite to coverage file(s) in a separate PR.

@MichaelLueken
Copy link
Collaborator

Thanks, @christinaholtNOAA! Will merge this PR now.

@MichaelLueken MichaelLueken merged commit d0bb3c5 into ufs-community:develop Jun 12, 2023
3 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
run_we2e_coverage_tests Run the coverage set of SRW end-to-end tests
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants