-
Notifications
You must be signed in to change notification settings - Fork 120
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] Update weather model, UPP, and UFS_UTILS hashes #1050
[develop] Update weather model, UPP, and UFS_UTILS hashes #1050
Conversation
…EMS with UFS, and update ush/set_ozone_param.py
… INPS namelist options for make_orog to work
…Scompact_25km_ics_HRRR_lbcs_RAP_suite_RRFS_v1beta configuration to remove DOT_OR_USCORE and specify_template_filenames configuration to rename NEMS to UFS
…ash to 945cb2c, and update spack-stack to v1.5.1
…set_ozone_param.py file has been removed, this test is no longer needed)
For more background information on this point, the stratospheric ozone physics schemes were reorganized (see ufs-community/ufs-weather-model#1851, NOAA-EMC/fv3atm#661, ufs-community/ccpp-physics#75) so that the ozone physics schemes are now controlled by input.nml, where previously they were controlled by both namelist and suite definition file. So any future ozone physics changes will need to be tied to the namelist options: currently the only supported ozone suite is the NRL 2015 ozone scheme ( |
@MichaelLueken I have run into a problem on Derecho that I'm unable to solve: this occurred both in my preliminary branch and your current branch. It has to do with the installation of the srw conda packages:
I assume we'll need to enlist the help of the unified workflow team on this one? Or it could be related to the updated spack-stack build. Regardless, I'll wait to see if you can replicate the problem to make sure it's not just a problem with my environment. |
@mkavulich I have just cloned a fresh copy of the
|
@MichaelLueken Did you check that the conda package installed correctly as well? The code actually builds successfully for me, it's the conda package that fails to install. |
@mkavulich Yes, the conda package was correctly installed. Both the My working copy on Derecho can be found - |
Thanks for confirming, and sorry for cluttering up the PR with my own issues. I did confirm that it works on Hera, so I'll continue my testing there while I try to figure out this Derecho issue. Edit: for future reference, this conda error was caused by my environment containing the environment variable TMPDIR which was pointing to a non-existent directory. This is the issue that helped me solve it: conda-forge/miniforge#474 |
…resolution tests to run successfully on Jet
…dd back in previously removed entries
…rom 4.9.3 to 5.0.6 to allow AQM testing to work
@MichaelLueken, I was able to build the app on Derecho successfully. However, after yesterday's PM, it fails on Hera with the following message:
This may be a system issue. Do you have any idea what happens there? |
I have updated my branch to the HEAD of
Please let me know if you continue to encounter issues while compiling or running on Hera. |
@MichaelLueken, it works well now. :) Thanks! |
…0 instead of 1.0.0
The update made to
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for adopting my suggested changes 👍
The Jenkins runner on Hera appears to have connected to a CentOS front end when maintenance concluded. The Jenkins tests on Hera failed to compile the SRW App. Reached out to the Platform Team via PSD-85 to request that they connect to a Rocky8 front end. Additionally, on Hera and Jet, the
Further investigation is necessary to see why the tests are running fine on Derecho, Hercules, and Orion, but not on Hera and Jet (Why is PBSpro okay, but not Slurm?). Additionally, why is there an issue with the wrapper scripts, but not when run as part of the workflow? The WE2E coverage tests were manually launched on Hera Intel and successfully passed:
|
As part of this PR, I removed the use of the PET list and added back in the original I'm now doing a deep dive to see if the PET list aspect of the weather model has been updated without an update to the documentation. |
I had been updating the Unfortunately, the
It appears as though the modification to |
…set 1 thread and only use 12 nodes
… Functional WorkflowTaskTests
The Jenkins tests successfully passed. After addressing conflicts, the AQM WE2E test was ran one last time and also successfully passed:
Merging this PR now. |
DESCRIPTION OF CHANGES:
This PR will update the ufs-weather-model hash to 8518c2c (March 1), the UPP hash to 945cb2c (January 23), and the UFS_UTILS hash to 57bd832 (February 6).
This work also required several modifications to allow the updated weather model and UFS_UTILS hashes to work in the SRW:
Type of change
TESTS CONDUCTED:
DEPENDENCIES:
None
DOCUMENTATION:
Documentation in ConfigWorkflow.rst has been updated to show renaming of NEMS/nems to UFS/ufs.
ISSUE:
Fixes #1049
CHECKLIST
CONTRIBUTORS (optional):
@mkavulich