-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add fv3-jedi and its dependencies (SkyLab 8 version) #395
base: spack-stack-dev
Are you sure you want to change the base?
Add fv3-jedi and its dependencies (SkyLab 8 version) #395
Conversation
…kylab7_components
@rhoneyager-tomorrow This replaces #306, correct? |
Yes. I can close the old version. |
@rhoneyager-tomorrow Let's see if we can get this PR merged/resolved. My preference would be to apply all the patches that you submitted here to the Skylab v8 release and then do away with anything prior to that in the spack PR. I would also prefer to pick apart this PR and add/update packages individually. For packages that are also in spack mainline, I would prefer submitting the updates to the upstream repo first and then bring them down to our fork. Other notes:
I can assist with or take care of some or most of this work, but hopefully we can split the work somewhat. Thoughts? |
@rhoneyager-tomorrow I am going to submit this to femps (note that I removed the
Does that look ok for you? |
Same for fv3-jedi-linearmodel:
|
variant("mpi", default=True, description="Support for MPI distributed parallelism") | ||
variant("openmp", default=True, description="Build with OpenMP support") | ||
|
||
conflicts("forecast_model=GEOS", msg="FV3-JEDI-LINEARMODEL: GEOS to be implemented.") |
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 we are using the current fv3-jedi-linearmodel with GEOS and UFS - @shlyaeva can you comment on this?
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.
You're using both, but at time of writing this PR GEOS wasn't fully buildable in Spack. Likewise, the ufs-bundle depended on JCSDA-internal, so I didn't have much insight there.
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 we can merge it as-is now, and update later as needed
depends_on("ecbuild", type=("build")) | ||
depends_on("[email protected]:", type=("build"), when="@3.0.7:") | ||
|
||
version("3.0.7", commit="1a02ebaf6f7a4e9f2c2d2dd973fb050e697bcc74") |
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 the non-standard notation of the tag. In the repo, it's v3.07
+++ b/CMakeLists.txt | ||
@@ -42,7 +42,7 @@ find_package( atlas 0.33.0 REQUIRED COMPONENTS OMP_Fortran ) | ||
if( ENABLE_MKL ) | ||
find_package( MKL ) |
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.
In fact, this should rather be
if( ENABLE_MKL )
find_package( MKL REQUIRED )
(at least that is what we decided at JCSDA - if you request a feature then it is an error if it is not available)
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.
Actually, we already have the change that you made in develop, and your version makes more sense than what I was thinking initially. That's because it's easier going to use Intel MKL or LAPACK, but if both are missing it will abort. I am going to revert that comment. I will make it a hard requirement if someone asks for MKL.
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.
My idea doesn't work, fixing the underlying problem requires changes across several repositories.
SkyLab 8 isn't released yet, but I expect that it will take some time for all the patches to be applied, so I'm quite fine with everything that you propose.
Great news! Hopefully you can do the same with mpas eventually.
Splitting works for me. Let me know once you finish reviewing. |
I created the PRs for femps and fv3-jedi-linearmodel so far based on what I posted above |
Regarding the ecmwf-atlas update: version 0.36.0 is already in spack develop, and I just opened spack#43133 to add the missing [email protected]: dependency. Once that's merged, I can bring both updates down to our fork. |
@rhoneyager-tomorrow We merged the femps and fv3-jedi-linearmodel build system bug fixes. Do you want to check the public develop branches? That will be in the Skylab v8 releases. |
@@ -20,6 +20,7 @@ class EcmwfAtlas(CMakePackage): | |||
|
|||
version("master", branch="master") | |||
version("develop", branch="develop") | |||
version("0.36.0", sha256="39bf748aa7b22df80b9791fbb6b4351ed9a9f85587b58fc3225314278a2a68f8") |
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.
Changes to this file will no longer be needed. We merged the missing [email protected]: dependency upstream (spack#43133); spack develop already had 0.36.0. We'll bring both updates to our spack fork shortly.
depends_on("netcdf-c") | ||
depends_on("netcdf-fortran") | ||
|
||
# find_package(ecbuild REQUIRED) is needed when using ecbuild. |
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.
Patches should no longer be required if we target sklyab v8
res = [self.define_from_variant("FV3_FORECAST_MODEL", "forecast_model")] | ||
return res | ||
|
||
# find_package(ecbuild REQUIRED) is needed when using ecbuild. |
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.
Patches should no longer be required if we target sklyab v8
@@ -0,0 +1,11 @@ | |||
--- a/CMakeLists.txt |
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.
No longer required for Skylab v8 because of JCSDA/GFDL_atmos_cubed_sphere#3
@rhoneyager-tomorrow Here is an update on the PR: I've merged the following patches (w/ slight modifications into the develop code, to be released in Skylab v8 next month):
I also updated the following package recipes in our spack fork:
What needs to remain in this PR (but updated to only cover the Skylab v8 versions):
|
Description
The previous PR (#306) has been around for a while. I have updated it for the new SkyLab v7 release.
This provides the same as before, with the addition of mom6 and soca packages.
Errata
I've excluded updates/additions of mpas-model and mpas-jedi from this PR. The mpas package on Spack is entirely incompatible with the JCSDA fork. CMake packaging logic vs a custom Makefile. I tested production of a CMake-ified version mpas-model package, but there is a bug in the CMake package export logic in the JCSDA fork, and this prevents use with mpas-jedi.
Checklist