Skip to content

zen vs zen2 inconsitency breaks modules() in spack load #13073

@bassenj

Description

@bassenj

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 found

Error 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.

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingmodules

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions