Various version updates for spack-stack-1.5.0 (parallelio, fms, met, metplus, eckit, fckit, fiat, ecmwf-atlas, scotch), set boost C++ std to C++-17 #722
Conversation
climbfuji
changed the title
climbfuji
changed the title
climbfuji
changed the title
…gs/containers/README.md
…tainers/README.md (the latter for UFS only)
climbfuji
force-pushed
the
feature/version_updates_20230817
branch
from
41f8ed5 to
846a622
Compare
climbfuji
changed the title
…eature/version_updates_20230817
…figs/sites/aws-pcluster/README.md, configs/sites/aws-pcluster/packages.yaml
climbfuji
changed the title
climbfuji
changed the title
climbfuji
changed the title
climbfuji
changed the title
…ack.yaml and configs/templates/unified-dev/spack.yaml
climbfuji
requested review from
srherbener,
AlexanderRichert-NOAA,
fmahebert and
ulmononian
…eature/version_updates_20230817
…id duplicate packages
…eature/version_updates_20230817
| # Various fms tags (list all to avoid duplicate packages) | ||
| - fms@release-jcsda | ||
| - fms@2023.01 | ||
| - fms@2023.02 |
There was a problem hiding this comment.
3 versions of fms moving forward? just wanted to double check. i saw this ufs-community/ufs-weather-model#1874, so assuming we retain 2023.01 for a while until all apps move to 2023.02?
There was a problem hiding this comment.
Also, re: #627, @climbfuji would it make sense to tie these to specific metapackages? If it already concretizes correctly then no worries, it's mostly an aesthetic thing for me.
| #version: ['2023.01'] | ||
| #variants: precision=32,64 +quad_precision +gfs_phys +openmp +pic constants=GFS build_type=Release | ||
| version: ['2023.02'] | ||
| variants: precision=32,64 +quad_precision +gfs_phys +openmp +pic constants=GFS build_type=Release +use_fmsio |
There was a problem hiding this comment.
jun's comment is addressed via the use_fmsio variant here, correct? (i.e.: ufs-community/ufs-weather-model#1874 (comment)).
There was a problem hiding this comment.
I think Jun is hoping to not having to use the deprecated fms_io component, but as she mentioned there is work that needs to be done. JEDI also needs fms_io. By enabling it (for now), we can simplify and speed up the transition to that version and abandon the old release-jcsda release.
|
Yes, we need ***@***.*** for the reasons you described and ***@***.*** for JEDI.
***@***.*** is for testing with and migration of both the UFS and JEDI to that version in the next quarter (it contains bug fixes from the older release-jcsda that are not in 2023.01). The good thing about this version is that once it works for both UFS and JEDI, we can stop using different versions of FMS altogether and just use 2023.02+ in the future.
… On Aug 23, 2023, at 11:03 AM, Cameron Book ***@***.***> wrote:
@ulmononian commented on this pull request.
In configs/templates/unified-dev/spack.yaml <#722 (comment)>:
> @@ -25,11 +25,13 @@ spack:
#- upp-env
#- ww3-env
- # Additional esmf/mapl tags
- #- ***@***.***~debug+external-parallelio
- #- ***@***.***~debug ***@***.***~debug+external-parallelio
+ # Various fms tags (list all to avoid duplicate packages)
+ - ***@***.***
+ - ***@***.***
+ - ***@***.***
3 versions of fms moving forward? just wanted to double check. i saw this ufs-community/ufs-weather-model#1874 <ufs-community/ufs-weather-model#1874>, so assuming we retain 2023.01 for a while until all apps move to 2023.02?
—
Reply to this email directly, view it on GitHub <#722 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RNKXJA67T63IZGBBZTXWYZWPANCNFSM6AAAAAA3U5FOWA>.
You are receiving this because you were assigned.
|
ok -- what a bright future! |
| variants: +python +grib2 | ||
| metplus: | ||
| version: ['5.0.1'] | ||
| version: ['5.1.0'] |
There was a problem hiding this comment.
since i think the srw is going to move toward using met/metplus modulefiles (rather than how it is currently done via path setting in the machine files), could we add met/metplus to the ufs-srw-app-env package.py?
|
Should I create an issue (similar to the “update ufs-weather-model-static template”) for this? I assume more updates are needed than just the met/metplus addition.
… On Aug 23, 2023, at 11:23 AM, Cameron Book ***@***.***> wrote:
@ulmononian commented on this pull request.
In configs/common/packages.yaml <#722 (comment)>:
> variants: +python +grib2
metplus:
- version: ['5.0.1']
+ version: ['5.1.0']
since i think the srw is going to move toward using met/metplus modulefiles (rather than how it is currently done via path setting in the machine files), could we add met/metplus to the ufs-srw-app-env package.py?
—
Reply to this email directly, view it on GitHub <#722 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RLLPRJAPZUKHQDYS5TXWY4C5ANCNFSM6AAAAAA3U5FOWA>.
You are receiving this because you were assigned.
|
sure. the srw template and package.py should both probably receive some upgrades. |
|
CI tests passed after the submodule pointer for spack following the merge of JCSDA/spack#304. Just waiting for the skylab-atm-land experiment to complete on AWS Parallel Cluster before merging. |
|
skylab-atm-land ran successfully. I think it's better to wait for @AlexanderRichert-NOAA's approval before merging. |
| # Various fms tags (list all to avoid duplicate packages) | ||
| - fms@release-jcsda | ||
| - fms@2023.01 | ||
| - fms@2023.02 |
There was a problem hiding this comment.
Also, re: #627, @climbfuji would it make sense to tie these to specific metapackages? If it already concretizes correctly then no worries, it's mostly an aesthetic thing for me.
|
@AlexanderRichert-NOAA It all concretizes ok, but if there is a better way I am happy to do that in a follow-up PR. I assume you mean something like but if yes it's not clear to me how to add the additional fms@2023.02 for testing/transitioning during the next quarter? |
Note - to be merged as merge commit, not as squashed commit
I made sure that each commit was for a specific package only. Merging this as a merge commit allows us to identify the individual commits.
Summary
Various version updates for spack-stack release 1.5.0 (all separate commits):
configs/common/packages.yamlandconfigs/containers/README.mdconfigs/common/packages.yamlandconfigs/containers/README.md(in the latter case for UFS only for now, before JEDI can use something else thanfms@release-jcsda, several PRs need to be merged).fms@2023.02the default version forufs-weather-model-env,ufs-srw-app-envandjedi-ufs-env, becausefms@2023.01is hardcoded in these virtual packages. Therefore, I addedfms@2023.02manually to theunified-devandskykab-devtemplates for now. This led to duplicate packages being concretized. I found that by adding all versions of fms and crtm explicitly in the skylab-dev and unified-dev specs, these duplicates could be avoided (a spack concretizer bug?)configs/common/packages.yamlconfigs/common/packages.yamlandconfigs/containers/README.mdconfigs/common/packages.yamlTesting
apple-clang@13.1.6/openmpi@4.1.5with JEDI/Skylab:qg-fullDA.yamll95-fullDA.yamlgfs-3dfgat-c12.yamlskylab-atm-land-small.yamlfv3jedi_test_tier1_model_ufs_warmstart,fv3jedi_test_tier1_forecast_ufs_warmstart)intel@2021.6.0/intel-oneapi-mpi) with JEDI/Skylab:fv3jedi_test_tier1_model_ufs_warmstart,fv3jedi_test_tier1_forecast_ufs_warmstart)Applications affected
All.
Systems affected
All.
Dependencies
Issue(s) addressed
Closes #706
Closes #709
Closes #591
Closes #727
Closes #646
Closes https://github.com/JCSDA-internal/skylab/issues/65
Closes #686
Closes #627
Working towards #702 (need to remove
ecmwf-atlasfrom automatically loaded modules forjedi-base-envmodule, but still build inunified-dev/skylab-devtemplates)Checklist