-
Notifications
You must be signed in to change notification settings - Fork 47
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 release/1.4.1 into develop #671
Merge release/1.4.1 into develop #671
Conversation
Update FMS & SCOTCH defaults
* Add libfabric to modules list in acorn/compilers.yaml * Update acorn/packages.yaml (incl. adding ext. flex) * update bufr default -> 12.0.0
JCSDA#669) * Update Hercules site config * Update mirrors for Hercules and Orion * Update configs/sites/gaea-c5/packages.yaml * Replace spack submodule release branch with tag * Update of doc/source/MaintainersSection.rst and doc/source/PreConfiguredSites.rst for spack-stack-1.4.1 * [skip ci] Doc updates for pre-configured sites Acorn and Parallel Works
.gitmodules
Outdated
##branch = develop | ||
#url = https://github.com/jcsda/spack | ||
#branch = jcsda_emc_spack_stack | ||
url = https://github.com/climbfuji/spack |
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.
This change is temporary and will be reverted once JCSDA/spack#296 is merged.
configs/sites/hercules/packages.yaml
Outdated
@@ -144,7 +144,7 @@ packages: | |||
qt: | |||
externals: | |||
- spec: [email protected] | |||
prefix: /apps/spack-managed/gcc-11.3.1/qt-5.15.8-d47tsna6f5dylcpblkfgw4gpn2cucihd | |||
prefix: /apps/spack-managed/gcc-12.2.0/qt-5.15.8-gayzhaahclvlybiiykwj2cym4vo33w6x |
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.
Note to self, this needs to be reverted. But it has no significance, since qt
isn't used in spack-stack directly.
@@ -20,7 +20,7 @@ | |||
version: [1.78.0] | |||
variants: ~atomic +chrono +date_time +exception +filesystem ~graph ~iostreams ~locale ~log ~math ~mpi ~numpy +pic +program_options +python ~random +regex +serialization ~signals +system +test +thread +timer ~wave cxxstd=14 visibility=hidden | |||
bufr: | |||
version: [11.7.1] | |||
version: [12.0.0] |
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 I'm good with making [email protected] the default version, but I want to double check. JEDI users should be using spack-stack-1.4.0 which has [email protected] installed. Because of this JEDI users will be insulated from this change so it's okay to make [email protected] the default version on the develop branch.
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.
Correct
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.
just a note: [email protected] is producing large differences in GSI regression tests (as reported by @DavidHuber-NOAA: NOAA-EMC/GSI#589 (comment)). fine to merge this here, but i expect there might be some issues w/ some applications during transition to this version.
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.
@ulmononian one thing to check would be if the GSI is currently using the [email protected] bufr_8 component (which is using 8-byte integers and 8-byte floats, ie double precision), or the bufr_d component (which has 4-byte integers and 8-byte floats). See the README.md notes at https://github.com/NOAA-EMC/NCEPLIBS-bufr/tree/bufr_v11.7.1 for details.
The only component available in [email protected] is bufr_4 which is 4-byte integers and 4-byte floats (ie single precision) so the GSI bufr related code could be making a switch from double to single precision.
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.
Let me note that if it turns out that we need both bufr@12 and bufr@11 in spack-stack-1.5.0, we can install both and configure the different environments (gsi-env etc.) such that they load the correct one.
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.
@srherbener Indeed, the GSI uses the bufr_d library, so that could explain the differences. Thanks!
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.
@srherbener thanks for providing that insight, steve. @DavidHuber-NOAA do you expect the GSI team to accept the differences w/ bufr_4 / bufr@12 or should we plan to provide bufr@11 for gsi purposes for the foreseeable 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.
@ulmononian I don't expect that they will accept it or at least that they will want to run some more testing before making the switch. Also, I don't see any hints on their GitHub page that they desire to upgrade at this time. But I have asked the question -- and will ask again on a different channel -- and will update when I hear back.
I'll go ahead and merge this. @DavidHuber-NOAA Please keep us posted if GSI needs bufr@11 (in addition to the existing bufr@12) in the next spack-stack-1.5.0 release (planned for early September). |
Summary
See title. This is pretty straightforward. I made the following change to the documentation after pulling in the release branch: The release branch had "spack-stack-1.4.1 not supported on this platform, please use 1.4.0" for a few selected machines. I replaced this with the original spack-stack-1.4.0 documentation and added a note on top that spack-stack-1.4.1 is not available on all platforms and that for those the documentation lists 1.4.0 further down.
Note. This should be merged as a regular merge, not as a squashed merge.
Testing
Both develop as of today and the release branch have undergone automatic and manual testing. For this PR, CI is sufficient.
Applications affected
This release enables the transition of the UFS to spack-stack, JEDI has only two minor version updates (eckit, bufr) that it will test in preparation for spack-stack-1.5.0.
Systems affected
See documentation update (but older 1.4.0 installations are still available).
Dependencies
Issue(s) addressed
Closes #637
Checklist