-
Notifications
You must be signed in to change notification settings - Fork 249
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
Esmf810 #188
Esmf810 #188
Conversation
@junwang-noaa I am going through my 777 (!) emails while I was on leave, then look at this PR first thing. |
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 so far, I am compiling the software stack for hera.gnu and will run the tests (including the parallel tests) afterwards.
@@ -355,11 +355,6 @@ SINGLE_NAME='' | |||
|
|||
TESTS_FILE='rt.conf' | |||
|
|||
if [[ $MACHINE_ID = orion.* ]]; then |
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.
Should we do the same with Cheyenne and Stampede in the future?
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.
I think so, but I think we may need an option to define which tests we will not run on a certain platforms.
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.
Yes, I remember we talked about this. Something like a -cheyenne.intel
, i.e. the -
negates running the test on that platform. Same for COMPILE
and RUN
lines. Not that for compile steps that work on all platforms, you can just use one COMPILE
line and leave the machine column empty.
ESMF 8.1.0 with parallel netcdf for hera.gnu
HWRF physics implementation in CCPP - addition of new CCPP schemes to ccpp_prebuild_config.py - update of suite definition files related to HWRF physics - update of GFS_typdefs.{F90,meta} with new/modified variables for HWRF physics - additional logic in FV3GFS_io.F90 for HWRF Noah LSM Co-authored-by: Jun.Wang <Jun.Wang@noaa.gov> Co-authored-by: Jili Dong <Jili.Dong@noaa.gov> Co-authored-by: Bin Liu <Bin.Liu@noaa.gov> Co-authored-by: Chunxi.Zhang-NOAA <Chunxi.Zhang@noaa.gov> Co-authored-by: andrew.hazelton <andrew.hazelton@noaa.gov> Co-authored-by: Jili.Dong@noaa.gov <Jili.Dong@v72a1.ncep.noaa.gov> Co-authored-by: ZhanZhang-NOAA <zhan.zhang@noaa.gov> Co-authored-by: Grant Firl <grantf@ucar.edu> Co-authored-by: Man.Zhang <Man.Zhang@noaa.gov> Co-authored-by: Dom Heinzeller <dom.heinzeller@noaa.gov>
Running on Cheyenne
Description
-Add GFSv16 performance tuning to fv3 develop branch.
-rt_orion.conf is merged into rt.conf, and orion baseline is moved to emc.nemspara account.
The baseline results will change because the isrctermprocessing is changed from 1 to 0, this will allow a more balanced regridding between fcst grid and write grid.
Issue(s) addressed
ufs-community/ufs-weather-model#142
Testing
How were these changes tested?
The RT test has been run on dell, cray, orion, is now running on cray.
What compilers / HPCs was it tested with?
Intel compiler.
Are the changes covered by regression tests?
Yes.
Dependencies
fv3atm PR #160
nems PR #76
These two PRs need to be committed first.