-
Notifications
You must be signed in to change notification settings - Fork 6
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
Spack Components for OM3 #171
base: main
Are you sure you want to change the base?
Conversation
Contributes to #163 |
This is still a draft but is ready for a review for style / approach. I've only implemented for CICE6 at this point, see the example deployment in ACCESS-NRI/ACCESS-OM3#35 |
Copied from access-om3-nuopc package
packages/access-cice/package.py
Outdated
url = "https://github.com/CICE-Consortium/CICE/archive/refs/tags/CICE6.6.0.tar.gz" | ||
version("6.6.0", md5="1c678c0af67bf09f92c0a861344c3a92") |
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.
url = "https://github.com/CICE-Consortium/CICE/archive/refs/tags/CICE6.6.0.tar.gz" | |
version("6.6.0", md5="1c678c0af67bf09f92c0a861344c3a92") |
Shall we pre-emptively create a version("access-om3", branch="main")
here ?
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.
How does this interact with the access3
variant?
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 CMake build will pick the correct "driver" code to work with dependencies built in access3-share
a.k.a the customisation in our fork are not essential for the model to build, but misses some nice to have customisation in our fork
I am not sure thats the question ?
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.
Hope that is helpful
depends_on("cmake@3.18:", type="build") | ||
depends_on("mpi") | ||
depends_on("netcdf-fortran@4.6.0:", when="io_type=NetCDF") | ||
depends_on("parallelio@2.5.10: build_type==RelWithDebInfo", when="io_type=PIO") |
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 is overriding the global build_type
variant. Is that intentional?
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 fear this turns off some optimisation which needs to be off for bfb repro, Ill investigate
packages/access3-share/package.py
Outdated
"build_type", | ||
default="Release", | ||
description="The build type to build", | ||
values=("Debug", "Release"), |
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 option for RelWithDebInfo
?
depends_on("esmf cflags='-fp-model precise' fflags='-fp-model precise'", when="%intel") | ||
depends_on("fortranxml@4.1.2:") | ||
|
||
depends_on("parallelio@2.5.10: build_type==RelWithDebInfo") |
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.
build_type
hard-coded.
packages/access-cice/package.py
Outdated
"build_type", | ||
default="Release", | ||
description="The build type to build", | ||
values=("Debug", "Release"), |
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 RelWithDebInfo
option?
depends_on("cmake@3.18:", type="build") | ||
depends_on("mpi") | ||
depends_on("netcdf-fortran@4.6.0:") | ||
depends_on("fms@2021.03: build_type==RelWithDebInfo precision=64 +large_file ~gfs_phys ~quad_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.
Hard codes build_type
and there is no build_type
variant as there is in other packages.
packages/access-mom6/package.py
Outdated
args.append(self.define("CMAKE_C_COMPILER", self.spec["mpi"].mpicc)) | ||
args.append(self.define("CMAKE_CXX_COMPILER", self.spec["mpi"].mpicxx)) | ||
args.append(self.define("CMAKE_Fortran_COMPILER", self.spec["mpi"].mpifc)) |
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.
These should no longer be necessary.
packages/access3-exe/package.py
Outdated
args.append(self.define("CMAKE_C_COMPILER", self.spec["mpi"].mpicc)) | ||
args.append(self.define("CMAKE_CXX_COMPILER", self.spec["mpi"].mpicxx)) | ||
args.append(self.define("CMAKE_Fortran_COMPILER", self.spec["mpi"].mpifc)) |
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.
Should no longer be needed I believe.
packages/access3-exe/package.py
Outdated
depends_on("mpi") | ||
|
||
for configurations in ["CICE6", "MOM6-CICE6", "MOM6-CICE6-WW3", "CICE6-WW3"]: | ||
depends_on("access-cice+cesmcoupled+access3") |
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.
Is this short-hand for:
depends_on("access-cice")
depends_on("cesmcoupled")
depends_on("access3")
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 cesmcoupled and access3 are variants in the access-cice package
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.
Is there a reason to have this separate package? Couldn't all this be just be put in the access-mom6
package?
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.
That is the extent of my high-level feedback. The rest is pretty low level I'm afraid.
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.
Did you leave this comment on the correct file ?
access3-exe
uses different code to access-mom6
...
We will at some point build models which don't include MOM6
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.
Sorry, I make a mistake in my comment:
Is there a reason to have this separate package? Couldn't all this be just be put in the access-om3 package?
Does that make more sense?
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 don't understand how versioning and CD would work if we did this.
i.e.
the version on the access-om3 deployment, is the version of a git tag in the access-nri/access-om3 release
the version on access3-exe is the version from the source code, i.e. the access-nri/access3-share repo
So I think we need a bundle package so we have something to version ? (ping @CodeGat )
This is an extremely draft collection of changes to
spack-packages
to build OM3 by component.I've been building access3-share with '+install_libraries' in the spec, I haven't looked at building with an executable yet
I've been using these git versions :
https://github.com/ACCESS-NRI/CICE/tree/5-port_cmake_build
and
https://github.com/ACCESS-NRI/access3-share/tree/share_prototype
Example deployment: ACCESS-NRI/ACCESS-OM3#35