-
Notifications
You must be signed in to change notification settings - Fork 172
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
Use a single spack.ver file #2844
Labels
feature
New feature or request
Comments
DavidHuber-NOAA
added
feature
New feature or request
triage
Issues that are triage
labels
Aug 20, 2024
KateFriedman-NOAA
added a commit
to KateFriedman-NOAA/global-workflow
that referenced
this issue
Sep 11, 2024
Update machine ver files to source combined spack.ver Refs NOAA-EMC#2844
bbakernoaa
pushed a commit
to bbakernoaa/global-workflow
that referenced
this issue
Sep 19, 2024
This PR updates the `develop` branch to use the newer operational `obsproc/v1.2.0` and `prepobs/v1.1.0`. The obsproc/prepobs installs in glopara space on supported platforms use tags cut from the `dev/gfsv17` branches in the respective repos. The installation of `prepobs/v1.1.0` on WCOSS2 is called "gfsv17_v1.1.0" to help avoid GFSv16 users using it instead of the operational module. Also, the `HOMEobsproc` path is updated to set an empty default for `obsproc_run_ver`. This both removes the need to set a default (and constantly update it, which is duplication) and avoid the unset variable error when the fcst jobs use their own load module script that does not know `obsproc_run_ver`: ``` export HOMEobsproc="${BASE_GIT:-}/obsproc/v${obsproc_run_ver:-}" ``` This PR also reverts the prepobs and fit2obs installs on MSU back to the glopara space from the temporary `/work/noaa/global/kfriedma/glopara` space installs. Lastly, this PR also includes updates to complete issue NOAA-EMC#2844 (merge `build.spack.ver` and `run.spack.ver`). Resolves NOAA-EMC#2291 Resolves NOAA-EMC#2840 Resolves NOAA-EMC#2844
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What new functionality do you need?
Currently, there are
build.spack.ver
andrun.spack.ver
version files. However, since the versions are not different when building or running, this should be reduced to a singlespack.ver
file and then allow the{machine}.build.ver
and{machine}.run.ver
files to source and use the needed versions fromspack.ver
.What are the requirements for the new functionality?
That
build.spack.ver
andrun.spack.ver
are combined intospack.ver
.Acceptance Criteria
All module loads are identical and no downstream changes.
Suggest a solution (optional)
No response
The text was updated successfully, but these errors were encountered: