[INSTALL]: met/metplus/python updates for EMC_verif-global

[AliciaBentley-NOAA]

Package name

met, metplus, python

Package version/tag

met-12.0.1, metplus-6.0.0, python-3.10.4

Build options

Current

Installation timeframe

Timeframe: ASAP to support EMC_verif-global in the global workflow using the latest version of spack-stack (1.9.1)
Machines: Gaea C6 (and Acorn/WCOSS2 after this)

Other information

Please keep all of the other Global Workflow dependencies available along with these updates to met-12.0.1, metplus-6.0.0, python-3.10.4 in spack-stack.

Installation steps

# in spack-stack-1.9.1/
. setup.sh
spack stack create env --name emc-gv-<compiler-version> --template empty --compiler <compiler@version> --site <site> --modify-pkg met --modify-pkg metplus --upstream <dir>
spack env activate emc-gv-<compiler-version>
spack add global-workflow-env ^metplus@6.0.0 ^met@12.0.1 gsi-env
for pkg in met metplus; do
  wget https://raw.githubusercontent.com/JCSDA/spack/refs/heads/spack-stack-dev/var/spack/repos/builtin/packages/${pkg}/package.py -O ${SPACK_ENV}/envrepo/packages/${pkg}/package.py
done
spack config add 'packages:met:require::["@12.0.1","+python","+grib2"]'
spack config add 'packages:metplus:require::["@6.0.0"]'
spack concretize -f |& tee ${SPACK_ENV}/log.concretize
spack install
spack module lmod refresh --upstream-modules
spack stack setup-meta-modules

[climbfuji]

met@12.0.1 and metplus@6.0.0 are already available in the unified environment, so that's good. I don't think we want to go back and support python@3.10.4 - we are on 3.11.11 in spack-stack-1.9.1?

[AliciaBentley-NOAA]

met@12.0.1 and metplus@6.0.0 are already available in the unified environment, so that's good. I don't think we want to go back and support python@3.10.4 - we are on 3.11.11 in spack-stack-1.9.1?

Thanks for bringing this up, @climbfuji . @AlexanderRichert-NOAA mentioned in a meeting that he would try python@3.10.4 first to see if using this version is possible. If it is not possible, then we can try python@3.11.11. We know that met@12.0.1 and metplus@6.0.0 can be build and run with python@3.10.4 (this has been thoroughly vetted). While met@12.0.1 and metplus@6.0.0 may work with python@3.11.11, this combination has not been tested by EMC or DTC. Thanks!

[climbfuji]

met@12.0.1 and metplus@6.0.0 are already available in the unified environment, so that's good. I don't think we want to go back and support python@3.10.4 - we are on 3.11.11 in spack-stack-1.9.1?

Thanks for bringing this up, @climbfuji . @AlexanderRichert-NOAA mentioned in a meeting that he would try python@3.10.4 first to see if using this version is possible. If it is not possible, then we can try python@3.11.11. We know that met@12.0.1 and metplus@6.0.0 can be build and run with python@3.10.4 (this has been thoroughly vetted). While met@12.0.1 and metplus@6.0.0 may work with python@3.11.11, this combination has not been tested by EMC or DTC. Thanks!

Ok, I'll assign this to @AlexanderRichert-NOAA then. NRL is using these versions of met and metplus with Python 3.11.11 without issues.

[AliciaBentley-NOAA]

met@12.0.1 and metplus@6.0.0 are already available in the unified environment, so that's good. I don't think we want to go back and support python@3.10.4 - we are on 3.11.11 in spack-stack-1.9.1?

Thanks for bringing this up, @climbfuji . @AlexanderRichert-NOAA mentioned in a meeting that he would try python@3.10.4 first to see if using this version is possible. If it is not possible, then we can try python@3.11.11. We know that met@12.0.1 and metplus@6.0.0 can be build and run with python@3.10.4 (this has been thoroughly vetted). While met@12.0.1 and metplus@6.0.0 may work with python@3.11.11, this combination has not been tested by EMC or DTC. Thanks!

Ok, I'll assign this to @AlexanderRichert-NOAA then. NRL is using these versions of met and metplus with Python 3.11.11 without issues.

@climbfuji Thank you! That is great information to know. Given the knowledge that NRL built and runs met@12.0.1 and metplus@6.0.0 with python@3.11.11, I think that we can potentially skip the initial test with python@3.10.4 and use python@3.11.11 from the start. Especially if using python 3.11.11 introduces fewer potential issues to the global workflow and spack-stack. Thanks!

CC @AlexanderRichert-NOAA

[AlexanderRichert-NOAA]

Thanks @climbfuji for the info. I'll go ahead and try it on Gaea C6 with the existing Python version in spack-stack (3.11) and we can go from there.

[AlexanderRichert-NOAA]

@AliciaBentley-NOAA I've installed those versions on Gaea C6. In your Gaea C6 module file, replace the path ending with "/modulefiles/Core" with the following: /autofs/ncrc-svm1_proj/epic/c6/spack-stack/spack-stack-1.9.1/envs/emc-gv-intel-2023.2.0/install/modulefiles/Core
To test loading up modules by hand, you can do

module use /autofs/ncrc-svm1_proj/epic/c6/spack-stack/spack-stack-1.9.1/envs/emc-gv-intel-2023.2.0/install/modulefiles/Core
module load stack-intel/2023.2.0 stack-python/3.11.7 stack-cray-mpich/8.1.30
module load met/12.0.1 metplus/6.0.0

[AlexanderRichert-NOAA]

On Acorn:
Intel 2022: /lfs/h1/emc/nceplibs/noscrub/spack-stack/spack-stack-1.9.1/envs/emc-gv-intel-2022/install/modulefiles/Core
Intel 19: /lfs/h1/emc/nceplibs/noscrub/spack-stack/spack-stack-1.9.1/envs/emc-gv-intel-19/install/modulefiles/Core