-
Notifications
You must be signed in to change notification settings - Fork 119
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
Update Cheyenne compilers #250
Update Cheyenne compilers #250
Conversation
update hpc-stack module path
@EdwardSnyder-NOAA - what is the current stack_cheyenne.yaml file in hpc-stack/stack/ directory that has the list of all modules built? (for the reference) |
@EdwardSnyder-NOAA - Your branch appears to be slightly behind develop. Would you mind updating it? Also, if the branch protection rules for develop do not already enforce incoming branches to be up-to-date (why isn't Gihub complaining about that) then someone with permissions really should check that box. Once Cheyenne returns from maintenance I can do an independent test. The changes looks good to me on (virtual) paper, but would like to do a quick build before approving. |
@christopherwharrop-noaa, thanks for the heads-up on the branch protection rules! I've updated them in both ufs-srweather-app and regional_workflow to require branches to be up-to-date with develop prior to merge. |
@natalie-perlin I couldn't find a stack_cheyenne.yaml file in hpc-stack/stack/ directory, so I'm guessing hpc-stack was built via stack_noaa.yaml or stack_custom.yaml. I was using the current build_cheyenne_intel, build_cheyenne_gnu, and srw_common modulefiles as a reference to what modules need to be loaded. |
@christopherwharrop-noaa - I have updated my branch with the latest changes from the ufs-srweather-app develop branch. Sounds good regarding testing on Cheyenne. |
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.
The build works as is. But now there are conflicts. Will have to retest after conflicts are resolved.
@EdwardSnyder-NOAA - I apologize for the delay in running the Cheyenne tests after maintenance. It looks like your existing changes work fine, but there have been some interim changes that conflict with yours. Would you mind updating your branch again to resolve the conflicts? |
@EdwardSnyder-NOAA - Thank you for the updates. This looks good to me. |
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.
Unfortunately, my approval was premature. The build fails on Hera with module loading issues due to changes in srw_common
.
$ ./devbuild.sh --platform=hera --compiler=intel --build-jobs=8 --clean
PLATFORM(MACHINE)=hera
COMPILER=intel
MODULE_FILE=build_hera_intel
Remove build directory
BUILD_DIR=..../tmp/ufs-srweather-app/build
... Load MODULE_FILE and create BUILD directory ...
Lmod has detected the following error: These module(s) or extension(s) exist but cannot be loaded as requested: "g2/3.4.5", "nemsio/2.5.4"
Try: "module spider g2/3.4.5 nemsio/2.5.4" to see how to load the module(s).
Executing this command requires loading "g2/3.4.5" which failed while processing the following module(s):
The problem is that the newer versions of
|
@EdwardSnyder-NOAA - I've also been dealing with modulefile issue for Cheyenne for my PR #269 . I was never successful in using the Gnu 10.1 stack as it appears to be broken in a few different ways. However, once I moved to the Gnu 11.2 stack, all my problems went away. I'd recommend taking a look in #269 to see whether anything in there helps. If the modulefiles for Cheyenne in #269 accomplish what you were trying to do, maybe this PR can be closed? I wasn't trying to redo your work elsewhere, but ended up having to make a number of Cheyenne related update that were needed for my own PR that happened to overlap with what you were doing here. I did try your solution first for my own work, but had a lot of problems with getting it to work across all the platforms. |
@christopherwharrop-noaa I noticed that PR #266 covered all the requested changes in this PR. As noted in PR 266 and in this PR, the proposed configuration doesn't build on Cheyenne but it sounds like your PR is handling that issue. I'm going to close this PR out, since the changes have been merged and the issue building on Cheyenne is being addressed. |
DESCRIPTION OF CHANGES:
Updated the hpc-stack used on Cheyenne for both GNU and Intel, so that updated versions of esmf, fms, and mapl could be used. For the Intel build, the compiler will change from version 2021.2 to 2022.1 and version of mpt 2.25 will be used instead of 2.22.
Summary of version changes in srw_common:
esmf: 8_2_0 --> 8.3.0b09
fms: 2021.03 --> 2021.04
mapl: 2.11.0-esmf-8_2_0 --> 2.11.0-esmf-8.3.0b09
png/1.6.35 --> libpng/1.6.35
Summary of version changes in build_cheyenne_intel:
hpc-intel: 2021.2 --> 2022.1
hpc-mpt: 2.22 --> 2.25
TESTS CONDUCTED:
The SRW App was pulled from the head of develop and built using the proposed changes for both GNU and Intel. The GST case was used to ensure the model ran successfully and was compared against the current configurations of GNU and Intel. No discrepancies were found for either compiler between the current configuration and the proposed changes.
DEPENDENCIES:
Add any links to external PRs (e.g. regional_workflow and/or UFS PRs). For example:
DOCUMENTATION:
No documentation changes are required.
ISSUE (optional):
This PR addresses the following issues:
CONTRIBUTORS (optional):
If others have contributed to this work aside from the PR author, list them here