Here are my notes for conflicts/changes/things in the spack submodule to watch out for:

first up: GREP FOR "DH* 20230710"

resolved conflicts in /.github/workflows/unit_tests.yaml

resolved conflicts in /.github/workflows/valid-style.yml

git checkout --theirs lib/spack/spack/environment/environment.py

git checkout --theirs lib/spack/spack/test/cmd/env.py

git checkout --theirs lib/spack/spack/test/env.py

resolved conflicts in  lib/spack/spack/test/modules/lmod.py

resolved conflicts in  share/spack/templates/container/singularity.def

resolved conflicts in  var/spack/repos/builtin/packages/esmf/package.py

resolved conflicts in  var/spack/repos/builtin/packages/fms/package.py

resolved conflicts in  var/spack/repos/builtin/packages/freetype/package.py

resolved conflicts in  var/spack/repos/builtin/packages/g2c/package.py

resolved conflicts in  var/spack/repos/builtin/packages/gettext/package.py

resolved conflicts in  var/spack/repos/builtin/packages/git/package.py

git checkout --theirs var/spack/repos/builtin/packages/glib/package.py

resolved conflicts in  var/spack/repos/builtin/packages/hdf/package.py

resolved conflicts in  var/spack/repos/builtin/packages/ip/package.py

resolved conflicts in  var/spack/repos/builtin/packages/libtiff/package.py

resolved conflicts in  var/spack/repos/builtin/packages/madis/package.py

resolved conflicts in  var/spack/repos/builtin/packages/mpich/package.py
--> FIXED TODO! SEND THIS RIGHT BACK TO SPACK DH* 20230710

git checkout --theirs var/spack/repos/builtin/packages/netcdf-c/package.py

resolved conflicts in  var/spack/repos/builtin/packages/openblas/package.py

resolved conflicts in  var/spack/repos/builtin/packages/py-contourpy/package.py

resolved conflicts in  var/spack/repos/builtin/packages/py-h5py/package.py

resolved conflicts in  var/spack/repos/builtin/packages/py-ruamel-yaml-clib/package.py

resolved conflicts in  var/spack/repos/builtin/packages/sp/package.py

git checkout --theirs var/spack/repos/builtin/packages/subversion/package.py

Major update/bug fix in var/spack/repos/builtin/packages/bufr/

Things to note:

1. One of the changes in spack now creates jedi-fv3-env/1.0.0 instead of xjedi-fv3-env/unified-dev. We should consider, in a follow-up PR, to replace the version 1.0.0 in the jcsda-emc-bundles packages.py with develop or main .

2. There is now a warning at the end of the spack install command on systems using lua that is annoying but doesn’t cause any harm:
   ==> Warning: detected custom TCL modules configuration in /mnt/experiments-efs/the-real-dom/sp-st-upd-20230710-tst/merge_dev_20230710/envs/unified-env/common, while TCL module file generation for the default module set is disabled. In Spack v0.20 module file generation has been disabled by default. To enable it run:

   $ spack config add 'modules:default:enable:[tcl]'
   That’s ok for now, but since we need to keep supporting tcl for dinosaur cray systems, we need to find a better way for spack-stack-1.5.0. Maybe have the lua/tcl module configs in separate files, detect from the site config used for spack stack create env which one is used (but may need an additional flag to override default lua for generic linux.default and macos.default) and the copy the correct one.

I have tested jedi-bundle on Orion (Intel/Impi) and all ctests pass except for one ioda converter test: test_iodaconv_ncep_bufr The reason this test fails is because the new [email protected] library build is installing the python module ncepbufr in the lib64 while the module file is setting up PYTHONTPATH to use lib.

This is a very minor (and easily fixable) fault and weighing this against thrashing Dom's feature branches to get this fixed now, it seems that the best path forward is to defer fixing this until after these PRs are merged in.

This fault is not interfering with my skylab testing, it shouldn't interfere with any other testing, and we should be able to get a fix for it in plenty of time for the 1.5.0 release.

What do others think?

@srherbener I'll look into it real quick and see if there's a straightforward way to fix it that won't require us to re-run tests. If not, then yes I'm okay with us making an issue for it and circling back to it later.

The skylab-atm-land test is working. The process completed two cycles successfully, which indicates that jedi-bundle and the software stack are good.

@srherbener I got a slightly different behavior when installing bufr on my machine (where it seems to install the python library both under lib/ and lib64/). If we're okay with proceeding for now, I'll create an issue and consult with the bufr and possibly spack developers and see where the issue lies.

@srherbener I got a slightly different behavior when installing bufr on my machine (where it seems to install the python library both under lib/ and lib64/). If we're okay with proceeding for now, I'll create an issue and consult with the bufr and possibly spack developers and see where the issue lies.

@AlexanderRichert-NOAA thanks for investigating into this. I am good with proceeding with the current [email protected] library configuration for now.

Also thanks for the further investigation with the bufr and spack developers!

@AlexanderRichert-NOAA @srherbener @ulmononian Thanks very much for getting this merged while I was away.

I am curious if @srherbener had to use spack concretize --reuse to convince spack to use the external libiconv, or if the changes in the macos.default packages.yaml were enough. Hopefully the hardcoded version in that file won't cause problems later.

@AlexanderRichert-NOAA @srherbener @ulmononian Thanks very much for getting this merged while I was away.

I am curious if @srherbener had to use spack concretize --reuse to convince spack to use the external libiconv, or if the changes in the macos.default packages.yaml were enough. Hopefully the hardcoded version in that file won't cause problems later.

I did not need to do spack concretize --reuse, ie the changes in the macos.default packages.yaml were enough to get it working on my Mac.

I'm not crazy about the hardcoded version number either. Perhaps there is a better way to do this?

@AlexanderRichert-NOAA @srherbener @ulmononian Thanks very much for getting this merged while I was away.
I am curious if @srherbener had to use spack concretize --reuse to convince spack to use the external libiconv, or if the changes in the macos.default packages.yaml were enough. Hopefully the hardcoded version in that file won't cause problems later.

I did not need to do spack concretize --reuse, ie the changes in the macos.default packages.yaml were enough to get it working on my Mac.

I'm not crazy about the hardcoded version number either. Perhaps there is a better way to do this?

I tried this again today - didn't need --reuse either.

I think I will have a better solution for libiconv today - detect it as an external package so that the version number is correct. Hopefully this works with the macOS "magic" you described earlier.

@climbfuji just a note. I tried to get spack external find to locate libiconv, but didn't have any luck. I think this was happening because the file /usr/lib/libiconv.dylib doesn't actually exist on the file system.

I recall reading somewhere that you have to use dlopen to detect /usr/lib/libiconv.dylib. I wonder if that means that we could write a short script/program for the mac that does the dlopen and then we could discover the true libiconv version that way. I think dlopen is accessible from python.