-
Notifications
You must be signed in to change notification settings - Fork 2.4k
zen vs zen2 inconsitency breaks modules() in spack load #13073
Description
After having some problem with the latest release, I was trying the current develop 66b9009 branch.
However, on develop, there seems to be an inconsistency with the architecture, that prohibits the use of modules. As a consequence, spack load does not work anymore. The issue is related to my architecture, Ubuntu 19.04 with kernel 5.3.0-050300rc3-generic, running on a Ryzen 3900X processor. I did not have the issue with a previous commit from the develop branch from one or two months ago. At that time my architecture was recognized as linux-ubuntu19.04-x86_64.
Steps to reproduce the issue
I started with a fresh clone and did the bootstrapping. The first use of spack load fails
$ git clone https://github.com/spack/spack.git
$ export SPACK_ROOT=/opt/spack
$ export PATH=$SPACK_ROOT/bin:$PATH
$ source $SPACK_ROOT/share/spack/setup-env.sh
$ export SPACK_SHELL="bash"
$ export EDITOR="vim"
$ spack bootstrap
...
$ spack load tcl
module: command not foundError Message
module should be a bash function, which it isn't here.
$ type module
-bash: type: module: not found
$ spack find
==> 3 installed packages
-- linux-ubuntu19.04-zen / [email protected] ----------------------------
[email protected] [email protected] [email protected]
$ spack --print-shell-vars modules
_sp_sys_type='linux-ubuntu19.04-zen2'
_sp_compatible_sys_types='linux-ubuntu19.04-zen2:linux-ubuntu19.04-zen:linux-ubuntu19.04-x86_64'
_sp_tcl_roots='/opt/spack/share/spack/modules'
_sp_lmod_roots='/opt/spack/share/spack/lmod'
_sp_module_prefix='not_installed'It is notable, that find shows the architecture as zen, whereas --print-shell-vars modules shows the architecture as zen2. 'not_installed' is the result of this inconsistency and breaks spack load.
Checking the difference in main.py reveals:
print('specs=%s' % spack.store.db.query('environment-modules arch=linux-ubuntu19.04-zen'))
>> specs=[environment-modules@4.3.1%gcc@8.3.0~X arch=linux-ubuntu19.04-zen ^tcl@8.6.8%gcc@8.3.0 arch=linux-ubuntu19.04-zen ^zlib@1.2.11%gcc@8.3.0+optimize+pic+shared arch=linux-ubuntu19.04-zen]print('specs=%s' % spack.store.db.query('environment-modules arch=linux-ubuntu19.04-zen2'))
>> specs=[]The latter happens in my case. The architecture is checked since e5b86c5 and microarchitectures are available since 3c4322b.
I don't know where the decision about the architecture is made but the inconsistency, that I have shown, prevents spack load from working.