Building ACCESS-OM2 on Archer2 (UK HPC)

Hi all,

I’ve just started trying to build ACCESS-OM2 on Archer2, the UK’s HPC platform, for a new project. I’ve found the forum phenomenally useful, although I’ve still managed to get myself stuck. Any help would be much appreciated, I’ll summarise what I’ve done so far below.

Archer2 is a Cray machine using SUSE:

[access-om2] munday@archer2 >> cat /etc/os-release
NAME="SLES"
VERSION="15-SP4"
VERSION_ID="15.4"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP4"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp4"
DOCUMENTATION_URL="https://documentation.suse.com/"

It also has spack already installed as a module. There are a couple of versions, I’ve (mostly) been using the default:

[access-om2] munday@archer2 >> module avail spack

-------------------------------------------------------- /mnt/lustre/a2fs-work4/work/y07/shared/archer2-lmod/others/core --------------------------------------------------------
   spack-epcc/0.21.2    spack/0.21.2    spack/1.0.2 (L,D)

  Where:
   L:  Module is loaded
   D:  Default Module
[access-om2] munday@archer2 >> spack --version
1.0.2

I’ve looked at a couple of topics on compiling on different machines (How to build ACCESS-OM2 on Setonix, Running ACCESS-OM2 on Leonardo supercomputer, Installing ACCESS-OM2 on NeSI (New Zealand supercomputer)) and started off by following the instructions on how to build on Gadi (Modify and build an ACCESS model's source code - ACCESS-Hive Docs). On Gadi the build was successful and from there I moved to trying on Archer2. I’ve been able to clone the git repo and create a spack environment:

munday@archer2 >> git clone https://github.com/ACCESS-NRI/ACCESS-OM2.git
munday@archer2 >> cd ACCESS-OM2
munday@archer2 >> spack env create access-om2 spack.yaml
**==>** Created environment access-om2 in: /work/n01/n01/munday/.spack-1.0.2/environments/access-om2
**==>** Activate with: spack env activate access-om2
munday@archer2 >> spack env activate access-om2
munday@archer2 >> spack install
**==>** Error: cannot concretize 'access-om2@git.2025.12.000=latest', since 'access-om2' does not exist
munday@archer2 >> spack concretize -f --fresh
**==>** Error: cannot concretize 'access-om2@git.2025.12.000=latest', since 'access-om2' does not exist

From reading the topics above I realised that I needed to tell Archer2 where to find things. I’ve been able to do that by cloning the spack-packages repo:

munday@archer2 >> spack env deactivate
munday@archer2 >> spack env status
**==>** No active environment
munday@archer2 >> git clone https://github.com/ACCESS-NRI/spack-packages.git --branch main
Cloning into 'spack-packages'...
remote: Enumerating objects: 2957, done.
remote: Counting objects: 100% (590/590), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 2957 (delta 503), reused 469 (delta 434), pack-reused 2367 (from 2)
Receiving objects: 100% (2957/2957), 629.88 KiB | 8.08 MiB/s, done.
Resolving deltas: 100% (1588/1588), done.
munday@archer2 >> spack repo list
[+] archer2 v2.2 /mnt/lustre/a2fs-nvme/work/y07/shared/apps/dev/spack/1.0.2/repos/archer2/spack_repo/archer2
[+] builtin v2.2 /work/n01/n01/munday/.spack-1.0.2/package_repos/fncqgg4/repos/spack_repo/builtin
munday@archer2 >> spack repo add spack-packages
**==>** Added repo to config with name 'access.nri'.
munday@archer2 >> spack repo list
[+] access.nri v1.0 /mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/ACCESS-OM2/spack-packages
[+] archer2 v2.2 /mnt/lustre/a2fs-nvme/work/y07/shared/apps/dev/spack/1.0.2/repos/archer2/spack_repo/archer2
[+] builtin v2.2 /work/n01/n01/munday/.spack-1.0.2/package_repos/fncqgg4/repos/spack_repo/builtin

At this point Archer2 seems to have located everything so I reactivated the spack environment to try concretize again.

munday@archer2 >> spack env activate access-om2
munday@archer2 >> spack concretize -f --fresh
**==>** Error: cannot load package 'access-mocsy' from the 'access.nri' repository: No module named ‘spack.build_systems'

I noticed that for Setonix it’s the access-spack-packages repo that is recommended. Swapping this out with spack-packages gives the same error message. If I use one of the other spack versions available on Archer2, I get a different error relating to access-mocsy:

munday@archer2 >> spack env activate access-om2
munday@archer2 >> spack concretize -f --fresh
==> Error: cannot load package 'access-mocsy' from the 'access.nri' repository: license() got an unexpected keyword argument 'checked_by'

I’m completely unfamiliar with spack, other than what I’ve picked up in the last couple of days. But this leads me to suspect some sort of version conflict or spack configuration issue. Poking around in the spack-config repo I see there are quite a few differences between the Gadi and Setonix spack configurations, although I don’t understand what’s going on here. If someone could point me in the right direction to figure this out, I’d be very grateful.

3 Likes

Hi Dave,

Welcome to the ACCESS-Hive Forum!

  1. Can you please provide the output of spack compiler list?

  2. If Archer2 has Spack already installed and available to users, then the Gadi instructions are not directly relevant. The Setonix instructions could be relevant.

  3. If you are using Spack v1.x, then you need to do git clone https://github.com/ACCESS-NRI/access-spack-packages --branch api-v2 because the main branch is for Spack v0.22 at the moment.

  4. If Archer2’s Spack instance recommends using GCC compilers, you may want to try: git clone https://github.com/ACCESS-NRI/ACCESS-OM2.git --branch api-v2-gcc instead of the main branch which is for Gadi.

Hi Harshula,

Thanks for getting back to me so quickly. Here’s the compiler list:

munday@archer2 >> spack compiler list
**==>** Available compilers
-- aocc sles15-x86_64 -------------------------------------------
[e] aocc@4.0.0

-- cce sles15-x86_64 --------------------------------------------
[e] cce@16.0.1

-- gcc sles15-x86_64 --------------------------------------------
[e] gcc@11.2.0 - gcc@7.5.0

I’m not particularly attached to any specific compiler, so I’m happy to use whatever actually works.

I’ll try out the branch for access-spack-packages and report back.

Many thanks,

Dave

Using the api-v2 branch for access-spack-packages did allow progress! After cleaning up a bit, I was able to clone the branch and add the access.nri repo to the spack list:

munday@archer2 >> git clone https://github.com/ACCESS-NRI/access-spack-packages --branch api-v2
Cloning into 'access-spack-packages'...
remote: Enumerating objects: 2957, done.
remote: Counting objects: 100% (590/590), done.
remote: Compressing objects: 100% (147/147), done.
remote: Total 2957 (delta 503), reused 469 (delta 434), pack-reused 2367 (from 2)
Receiving objects: 100% (2957/2957), 629.88 KiB | 7.78 MiB/s, done.
Resolving deltas: 100% (1588/1588), done.

[access-om2] munday@archer2 >> cd access-spack-packages/spack_repo/access/nri

[access-om2] munday@archer2 >> spack repo add .
==> Added repo to config with name 'access.nri'.
[access-om2] munday@archer2 >> spack repo list
[+] access.nri    v2.0    /mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/ACCESS-OM2/access-spack-packages/spack_repo/access/nri
[+] archer2       v2.2    /mnt/lustre/a2fs-nvme/work/y07/shared/apps/dev/spack/1.0.2/repos/archer2/spack_repo/archer2
[+] builtin       v2.2    /work/n01/n01/munday/.spack-1.0.2/package_repos/fncqgg4/repos/spack_repo/builtin

To get spack repo add to succeed, you can see I had to cd to the location of the repo.yaml. Otherwise it failed with

[access-om2] munday@archer2 >> spack repo list
[-] access.nri            /mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/ACCESS-OM2/access-spack-packages:
No repo.yaml found in '/mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/ACCESS-OM2/access-spack-packages'

The concretize command also progressed. It took much longer to do anything, which I took as a good sign :slight_smile: Alas, it still failed with the following error:

[access-om2] munday@archer2 >> spack concretize -f --fresh
==> Error: failed to concretize `access-om2@git.2025.12.000=latest` for the following reasons:
     1. cannot satisfy a requirement for package 'access-om2'.
     2. No valid value for variant 'deterministic' of package 'access-om2'

Google pointed me to the list of random spack errors: Random spack errors/tips/fixes - #39 by harshula. I’d used the --fresh flag, so I’ll have to dig around a bit tomorrow to figure things out and try gcc.

This is progress! Thanks very much.

2 Likes

Hi Dave,
Cool to see you are also trying to do something similar as me on the NZ system.
So, my one piece of advice here is that I have had problems with MOM5 when it’s compiled using GCC. The model can complete the compilation but then it crashes quickly at runtime, and I think it’s because of problems with the BOZ literals specified in the MPP domains part of the code, i.e. here:

And several other examples in that module. I have found that Intel compilers can handle this setting just fine, so switching to Intel compilers seems to be the way to go here.

But, since NeSI (the NZ machine) is an AMD computer, this poses some issues. When I compile using an Intel compiler, I have to change the optimisation flags to remove the “CORE_AVX2” setting. (That also causes a crash immediately at runtime, despite the compilation seemingly “working”.)

I have been able to get a standalone MOM5 executable to work on NeSI when using Intel compilers and removing the CORE_AVX2 vectorisation flag manually. I haven’t yet got it integrated into the Spack workflow, hence I am still not there yet on getting ACCESS-OM2 to work.

But I will update the forum (and tag you) if/when I manage to get there.

Regards,
David

1 Like

According to this documentation

BOZ literal constants were only allowed to be set via DATA statements up to Fortran 95. So the current code would require f95 or greater.

What standard does your gcc compiler support?

Hi Aidan,
I’m afraid I can’t really answer that - I just don’t know how they work. What I can say is that I’ve tried to install MOM5 with GCC compilers on two different NZ clusters, and both times it choked at the MPP domains set up part of the code. Note: error occurred at runtime, not during compilation.

In both cases, switching to Intel solved the problem, but like I said, I also had to get rid of CORE_AVX2 vectorisation because they were both AMD machines that didn’t like that.

P.S. I had to use this flag during the GCC compilation:
-fallow-invalid-boz
as per your link

At the risk of derailing this even further … it seems BOZ literals have been a source of some confusion that various iterations of the standard have spectacularly failed to address

(Steve Lionel was Mr Intel Fortran for many years, and a very authoritative source)

It is probably worth trying something like this for the three BOZ literal variable initialisation statements:

integer(LONG_KIND), parameter :: ADDR2_BASE=int(Z'0000000000010000', kind=LONG_KIND)

to see if this fixes it.

1 Like

I think I tried that and had no luck. It’s possible I missed something… definitely beyond my knowledge base.

1 Like

Hi Dave,

Can you please try:

git clone https://github.com/ACCESS-NRI/ACCESS-OM2.git --branch api-v2-archer2
spack env activate -p ./ACCESS-OM2
spack concretize -f --fresh
spack install

Hi Harshula,

I started fresh with your branch and worked through the steps.

munday@archer2 >> mkdir API-V2-ARCHER2
munday@archer2 >> cd API-V2-ARCHER2/
munday@archer2 >> https://github.com/ACCESS-NRI/ACCESS-OM2.git --branch api-v2-archer2
-bash: https://github.com/ACCESS-NRI/ACCESS-OM2.git: No such file or directory
munday@archer2 >> git clone https://github.com/ACCESS-NRI/ACCESS-OM2.git --branch api-v2-archer2
Cloning into 'ACCESS-OM2'...
remote: Enumerating objects: 696, done.
remote: Counting objects: 100% (226/226), done.
remote: Compressing objects: 100% (102/102), done.
remote: Total 696 (delta 184), reused 137 (delta 124), pack-reused 470 (from 2)
Receiving objects: 100% (696/696), 213.12 KiB | 4.02 MiB/s, done.
Resolving deltas: 100% (361/361), done.

The environment activates OK, it just doesn’t concretize:

munday@archer2 >> spack env activate -p ./ACCESS-OM2
[ACCESS-OM2] munday@archer2 >> spack concretize -f --fresh
==> Error: cannot concretize 'access-om2@git.2025.09.000=latest', since 'access-om2' does not exist

I recloned a fresh copy of access-spack-packages in my current location:

[ACCESS-OM2] munday@archer2 >> git clone https://github.com/ACCESS-NRI/access-spack-packages --branch api-v2
Cloning into 'access-spack-packages'...
remote: Enumerating objects: 3002, done.
remote: Counting objects: 100% (592/592), done.
remote: Compressing objects: 100% (183/183), done.
remote: Total 3002 (delta 455), reused 467 (delta 381), pack-reused 2410 (from 2)
Receiving objects: 100% (3002/3002), 641.76 KiB | 85.00 KiB/s, done.
Resolving deltas: 100% (1601/1601), done.
[ACCESS-OM2] munday@archer2 >> spack repo list
[+] archer2    v2.2    /mnt/lustre/a2fs-nvme/work/y07/shared/apps/dev/spack/1.0.2/repos/archer2/spack_repo/archer2
[+] builtin    v2.2    /work/n01/n01/munday/.spack-1.0.2/package_repos/fncqgg4/repos/spack_repo/builtin
[ACCESS-OM2] munday@archer2 >> spack repo add access-spack-packages/
==> Warning: Skipping package repository '/mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/API-V2-ARCHER2/access-spack-packages' due to: No repo.yaml found in '/mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/API-V2-ARCHER2/access-spack-packages'
==> Error: No package repository could be constructed from access-spack-packages/

In the wrong place, oops:

[ACCESS-OM2] munday@archer2 >> cd access-spack-packages/spack_repo/access/nri/
[ACCESS-OM2] munday@archer2 >> spack repo add .
==> Added repo to config with name 'access.nri'.
[ACCESS-OM2] munday@archer2 >> spack repo list
[+] access.nri    v2.0    /mnt/lustre/a2fs-work1/work/n01/n01/munday/SO-SIMMER/API-V2-ARCHER2/access-spack-packages/spack_repo/access/nri
[+] archer2       v2.2    /mnt/lustre/a2fs-nvme/work/y07/shared/apps/dev/spack/1.0.2/repos/archer2/spack_repo/archer2
[+] builtin       v2.2    /work/n01/n01/munday/.spack-1.0.2/package_repos/fncqgg4/repos/spack_repo/builtin

With the repo located I can start the concretize and the first error (1. cannot satisfy a requirement for package 'access-om2'.) has been resolved. The second error is still occurring:

[ACCESS-OM2] munday@archer2 >> pwd
/work/n01/n01/munday/SO-SIMMER/API-V2-ARCHER2/access-spack-packages/spack_repo/access/nri
[ACCESS-OM2] munday@archer2 >> cd ../../../../
[ACCESS-OM2] munday@archer2 >> ls
ACCESS-OM2  access-spack-packages
[ACCESS-OM2] munday@archer2 >> spack concretize -f --fresh
==> Error: failed to concretize `access-om2@git.2025.09.000=latest` for the following reasons:
     1. No valid value for variant 'deterministic' of package 'access-om2'

I’ve been poking around to see if this is something I can flick off, doesn’t seem to crop up anywhere.

Thanks, D

More by way of documenting somewhere what I’ve been doing, I thought I’d continue to update, despite not really getting anywhere!

Following the advice here: Debug Spack "Error: failed to concretize", I’ve looked into the concretize error by trying individual components. Consistently I get issues with netcdf-fortran and netcdf-c.

[ACCESS-OM2] munday@archer2 >> spack solve cice5
==> Error: failed to concretize `cice5` for the following reasons:
     1. cannot satisfy a requirement for package 'netcdf-fortran'.
     2. cannot satisfy a requirement for package 'netcdf-c'.

To try and obtain more information, I deactivated the spack env and tried to install netcdf-fortran. This causes a conflict with an external module:

munday@archer2 >> spack install netcdf-fortran
==> netcdf-fortran@4.9.0.7 : has external module in ['cray-hdf5-parallel/1.12.2.7', 'cray-netcdf-hdf5parallel']
[+] /opt/cray/pe/netcdf-hdf5parallel/4.9.0.7/gnu/9.1 (external netcdf-fortran-4.9.0.7-5ls7gh4entsmweu3fuk577s5ystzn5wt)

A curious thing here is that I didn’t have the cray-hd5-parallel or cray-netcdf-hdf5parallel modules loaded. I use MITgcm the most and so my default modules are the ones I use for its compilation: cray-netcdf/4.9.0.7 and cray-hdf5/1.12.2.7.

munday@archer2 >> module list

Currently Loaded Modules:
  1) craype-x86-rome            5) xpmem/0.2.119-1.3_0_gnoinfo   9) cray-mpich/8.1.27      13) epcc-setup-env       17) cray-python/3.10.10  21) spack/1.0.2
  2) libfabric/1.12.1.2.2.0.0   6) cce/16.0.1                   10) cray-libsci/23.09.1.1  14) load-epcc-module     18) nco/5.1.6
  3) craype-network-ofi         7) craype/2.7.23                11) PrgEnv-cray/8.4.0      15) cray-hdf5/1.12.2.7   19) ncview/2.1.11
  4) perftools-base/23.09.0     8) cray-dsmml/0.2.2             12) bolt/0.8               16) cray-netcdf/4.9.0.7  20) other-software/1.0

If I try to install a specific netcdf-fortran or netcdf-c version I get a much longer error message:

munday@archer2 >> spack install netcdf-fortran@=4.6.2
==> Error: failed to concretize `netcdf-fortran@=4.6.2` for the following reasons:
     1. Cannot satisfy 'netcdf-fortran@=4.6.2'
        required because netcdf-fortran@=4.6.2 requested explicitly 
     2. Cannot satisfy 'netcdf-fortran@=4.6.2'
     3. Cannot satisfy 'netcdf-fortran@=4.9.0.7' and 'netcdf-fortran@=4.6.2
        required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %aocc 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %gcc 
            required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %cce 
              required because netcdf-fortran@=4.6.2 requested explicitly 
            required because netcdf-fortran@=4.6.2 requested explicitly 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %cce 
          required because netcdf-fortran@=4.6.2 requested explicitly 
        required because netcdf-fortran@=4.6.2 requested explicitly 
     4. Cannot satisfy 'netcdf-fortran@=4.9.0.7' and 'netcdf-fortran@=4.6.2
        required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %cce 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %gcc 
            required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %aocc 
              required because netcdf-fortran@=4.6.2 requested explicitly 
            required because netcdf-fortran@=4.6.2 requested explicitly 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %aocc 
          required because netcdf-fortran@=4.6.2 requested explicitly 
        required because netcdf-fortran@=4.6.2 requested explicitly 
     5. Cannot satisfy 'netcdf-fortran@=4.9.0.7' and 'netcdf-fortran@=4.6.2
        required because netcdf-fortran@=4.6.2 requested explicitly 
        required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %gcc 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %cce 
            required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %aocc 
              required because netcdf-fortran@=4.6.2 requested explicitly 
            required because netcdf-fortran@=4.6.2 requested explicitly 
          required because netcdf-fortran available as external when satisfying netcdf-fortran@=4.9.0.7 %aocc 
          required because netcdf-fortran@=4.6.2 requested explicitly 

It doesn’t matter whether the cray-netcdf module is loaded, or not.

Hi Dave,

Great work identifying that installing netcdf-fortran fails. Since that is an upstream Spack Package Recipe (SPR), you can get help directly from Spack upstream. Is this meeting day/time convenient for you? Telcon: 2026 02 11 · spack/spack Wiki · GitHub

Hi Dave,

Unfortunately that’s 2am in the UK! Things are progressing, but I can this if they stall.

Isn’t Wednesday February 11th, 9am PT (UTC -8:00), 5pm in the UK?

The only explanation I can think here is that the module provides both C and Fortran bindings, so the version is corresponding to the C bindings as the highest version number? I poked around in the spack list of packages and the available netcdf-fortran there goes up to 4.6.1 and netcdf-c goes up to 4.9.2.

I updated to this commit before I tried anything else. Unfortunately, the concretize still failed with the same error.

On the other hand, deleting this lines from spack.yaml gave a successful concretize and a partially successful spack install with my default modules loaded.

[ACCESS-OM2] munday@archer2 >> spack concretize -f --fresh
==> Starting concretization
==> Concretized 1 spec:
 -   5iccke6  access-om2@git.2025.09.000=latest~deterministic build_system=bundle commit=cbb0ea3106a9c32da491c36c9759773405abedc5 arch=linux-sles15-x86_64 
 -   rocaocv      ^cice5@git.2025.03.001=access-om2~deterministic~optimisation_report build_system=makefile commit=4cc7abd9875153a8114647fd3317a31993fdf80d direct_ldflags=none model=access-om2 arch=linux-sles15-x86_64 %c,fortran=gcc@11.2.0
[+]  ln4fjkb          ^compiler-wrapper@1.0 build_system=generic arch=linux-sles15-x86_64 
[e]  ipht6ms          ^cray-mpich@8.1.27~cuda~rocm+wrappers build_system=generic arch=linux-sles15-x86_64 
[+]  3zmdsfr          ^datetime-fortran@1.7.0 build_system=autotools patches:=80b9577 arch=linux-sles15-x86_64 %fortran=gcc@11.2.0
[e]  25lifqe          ^gcc@11.2.0~binutils+bootstrap~graphite~nvptx~piclibs~profiled~strip build_system=autotools build_type=RelWithDebInfo languages:='c,c++,fortran' patches:=0d13622,cc6112d arch=linux-sles15-x86_64 
[+]  dedsb32          ^gcc-runtime@11.2.0 build_system=generic arch=linux-sles15-x86_64 
[e]  grfew3z          ^glibc@2.31 build_system=autotools arch=linux-sles15-x86_64 
[e]  pupuskg          ^gmake@4.2.1~guile build_system=generic patches:=ca60bd9,fe5b60d arch=linux-sles15-x86_64 
[e]  vpkftxe          ^netcdf-c@4.9.0.7+blosc~byterange~dap~fsync~hdf4~jna~logging+mpi~nczarr_zip+optimize~parallel-netcdf+pic+shared+szip+zstd build_system=autotools patches:=0161eb8 arch=linux-sles15-x86_64 
[e]  iwywuqn          ^netcdf-fortran@4.9.0.7~doc+pic+shared build_system=autotools arch=linux-sles15-x86_64 
 -   arxeo45          ^oasis3-mct@git.2025.03.001=2025.03.001~deterministic~optimisation_report build_system=makefile commit=48a76126fc00932e50af19617f3dba7a154717c6 arch=linux-sles15-x86_64 %c,fortran=gcc@11.2.0
[+]  nvufwls          ^parallelio@2.6.2+fortran~ipo~logging+mpi~ncint~pnetcdf~shared~timing build_system=cmake build_type=Release generator=make arch=linux-sles15-x86_64 %c,cxx,fortran=gcc@11.2.0
 -   un4omez      ^libaccessom2@git.2025.05.001=access-om2~deterministic~ipo~optimisation_report build_system=cmake build_type=Release commit=bbc8c898d8a8e064871c7bf291d1fdb20b44f3e8 generator=make arch=linux-sles15-x86_64 %fortran=gcc@11.2.0
[e]  wyamiap          ^cmake@3.20.4~doc+ncurses+ownlibs~qtgui build_system=generic build_type=Release arch=linux-sles15-x86_64 
[+]  mui6so3          ^json-fortran@8.3.0~ipo build_system=cmake build_type=Release generator=make arch=linux-sles15-x86_64 %fortran=gcc@11.2.0
[e]  dbhmu3w          ^pkg-config@0.29.2+internal_glib build_system=autotools arch=linux-sles15-x86_64 
 -   fet6dox      ^mom5@git.2025.08.000=access-om2~deterministic~ipo build_system=cmake build_type=RelWithDebInfo commit=627a321f7490afc69b4a8e777992bcfb1f58b5ae generator=make arch=linux-sles15-x86_64 %c,fortran=gcc@11.2.0
[+]  vauuweq          ^access-fms@git.mom5-2025.05.000=mom5 cppflags='-DMAXFIELDMETHODS_=600' ~gfs_phys+internal_file_nml~ipo~large_file~pic~shared build_system=cmake build_type=Release commit=bf9b80423ea4f66efa389e03d3c19b26c009e8b6 generator=make arch=linux-sles15-x86_64 %c,cxx,fortran=gcc@11.2.0
 -   tbg7gac          ^access-generic-tracers@2025.09.000~ipo~shared+use_access_fms build_system=cmake build_type=Release commit=8454a9f569782fd7bb5efbaf8b993cf6f14de2de generator=make arch=linux-sles15-x86_64 %fortran=gcc@11.2.0
 -   loldyro              ^access-mocsy@2025.07.002~ipo~shared build_system=cmake build_type=RelWithDebInfo commit=bfbf7f87244bb42db53cd304ddfead567e990312 generator=make precision=2 arch=linux-sles15-x86_64 %c,fortran=gcc@11.2.0

The spack install itself is turning up some more errors for me to investigate.

[ACCESS-OM2] munday@archer2 >> spack install
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/none-none/compiler-wrapper-1.0-ln4fjkbeapeb4tzzk2iuplqg4j4xwku7
==> cray-mpich@8.1.27 : has external module in ['cray-mpich/8.1.27', 'craype-network-ofi']
[+] /opt/cray/pe/mpich/8.1.27/ofi/gnu/9.1 (external cray-mpich-8.1.27-ipht6msnc7xnfvx4tft6iklcwqzyrf7c)
[+] /usr (external glibc-2.31-grfew3zdwmu3xqna7shzzgfv2hszc56g)
==> gcc@11.2.0 : has external module in ['cpe/23.09', 'PrgEnv-gnu', 'gcc/11.2.0', 'xpmem', 'libfabric', 'craype-x86-rome', 'craype-network-ofi']
[+] /opt/cray/libfabric/1.12.1.2.2.0.0 (external gcc-11.2.0-25lifqed3rrpsmudbumxvmmhoc6hf3rs)
[+] /usr (external gmake-4.2.1-pupuskgdqrv7vtyyob2urc2pqev7rkdl)
[+] /usr (external cmake-3.20.4-wyamiap6s3dercj5aawrr5zpipobwsmb)
==> netcdf-fortran@4.9.0.7 : has external module in ['cray-hdf5-parallel/1.12.2.7', 'cray-netcdf-hdf5parallel']
[+] /opt/cray/pe/netcdf-hdf5parallel/4.9.0.7/gnu/9.1 (external netcdf-fortran-4.9.0.7-iwywuqn2jlbyplitboktyy4ym6zmjd6e)
[+] /usr (external pkg-config-0.29.2-dbhmu3whpfnecwmazpopux4gjv3dz5ho)
==> netcdf-c@4.9.0.7 : has external module in ['cray-hdf5-parallel/1.12.2.7', 'cray-netcdf-hdf5parallel']
[+] /opt/cray/pe/netcdf-hdf5parallel/4.9.0.7/gnu/9.1 (external netcdf-c-4.9.0.7-vpkftxex66ttdvdrfcjazqf4ygjt6elk)
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/none-none/gcc-runtime-11.2.0-dedsb32ucp3n2fhyqm57p5gn6giqr42d
==> No binary for oasis3-mct-git.2025.03.001=2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg found: installing from source
==> Installing oasis3-mct-git.2025.03.001=2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg [11/21]
==> Using cached archive: /work/n01/n01/munday/.spack-1.0.2/var/spack/cache/_source-cache/git//ACCESS-NRI/oasis3-mct.git/48a76126fc00932e50af19617f3dba7a154717c6.tar.gz
==> No patches needed for oasis3-mct
==> oasis3-mct: Executing phase: 'edit'
==> oasis3-mct: Executing phase: 'build'
==> Error: ProcessError: Command exited with status 2:
    'make' '-f' 'TopMakefileOasis3'

7 errors found in build log:
     69    Please check the Makefile.conf
     70    Have a nice day!
     71    make[2]: Entering directory '/tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-src/compile_oa3-mct/bu
           ild/lib/mctdir'
     72    make[3]: Entering directory '/tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-src/compile_oa3-mct/bu
           ild/lib/mctdir/mpeu'
     73    gcc -c -DSYSLINUX -DCPRCOMPAQ  -g -O2   -I. -I../ get_zeits.c
     74    mpif90 -Wall -fallow-argument-mismatch -ffree-line-length-0 -c  -I. -I../ -DSYSLINUX -DCPRCOMPAQ -fast     m_mpif.F90
  >> 75    gfortran: error: unrecognized command-line option '-fast'; did you mean '-Ofast'?
  >> 76    make[3]: *** [Makefile:71: m_mpif.o] Error 1
     77    make[3]: Leaving directory '/tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-src/compile_oa3-mct/bui
           ld/lib/mctdir/mpeu'
  >> 78    make[2]: *** [Makefile:10: subdirs] Error 2
     79    make[2]: Leaving directory '/tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-src/compile_oa3-mct/bui
           ld/lib/mctdir'
  >> 80    cp: cannot stat './*/lib*.a': No such file or directory
  >> 81    cp: cannot stat './*/*.mod': No such file or directory
  >> 82    make[1]: *** [TopMakefileOasis3:60: makemct] Error 1
     83    make[1]: Leaving directory '/tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-src/util/make_dir'
  >> 84    make: *** [TopMakefileOasis3:28: default] Error 2

See build log for details:
  /tmp/munday/spack-stage/spack-stage-oasis3-mct-git.2025.03.001_2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg/spack-build-out.txt

==> Warning: Skipping build of mom5-git.2025.08.000=access-om2-fet6dox3rgcxnmdoppbeqwtpofgketwv since oasis3-mct-git.2025.03.001=2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg failed
==> Warning: Skipping build of access-om2-git.2025.09.000=latest-5iccke6jm2b6znvbj27n7wp3kepded43 since mom5-git.2025.08.000=access-om2-fet6dox3rgcxnmdoppbeqwtpofgketwv failed
==> Warning: Skipping build of libaccessom2-git.2025.05.001=access-om2-un4omezbi553jkpamlmcvhpfidnn7de6 since oasis3-mct-git.2025.03.001=2025.03.001-arxeo4544forf5wuocbb4zyefl3m4bxg failed
==> Warning: Skipping build of cice5-git.2025.03.001=access-om2-rocaocvun5veqoqap2x2zb77d57zw6e5 since libaccessom2-git.2025.05.001=access-om2-un4omezbi553jkpamlmcvhpfidnn7de6 failed
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/json-fortran-8.3.0-mui6so3iq6xuhkfjufdwhnd7ouzrfu6b
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/datetime-fortran-1.7.0-3zmdsfrl4yms5wxnfew6zhdawfhlnecz
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/parallelio-2.6.2-nvufwlswt3qhbnghcqjglci7iiwcvul5
[+] /work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/access-fms-git.mom5-2025.05.000_mom5-vauuweqqnhmxura3ri7f4voqgetec7gq
==> No binary for access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn found: installing from source
==> Installing access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn [16/21]
==> Using cached archive: /work/n01/n01/munday/.spack-1.0.2/var/spack/cache/_source-cache/git//ACCESS-NRI/mocsy.git/bfbf7f87244bb42db53cd304ddfead567e990312.tar.gz
==> Warning: Using download cache instead of version control
  The required sources are normally checked out from a version control system, but have been archived in download cache: file:///work/n01/n01/munday/.spack-1.0.2/var/spack/cache/_source-cache/git//ACCESS-NRI/mocsy.git/bfbf7f87244bb42db53cd304ddfead567e990312.tar.gz. Spack lacks a tree hash to verify the integrity of this archive. Make sure your download cache is in a secure location.
==> No patches needed for access-mocsy
==> access-mocsy: Executing phase: 'cmake'
==> Error: ProcessError: Command exited with status 1:
    '/usr/bin/cmake' '-G' 'Unix Makefiles' '-DCMAKE_INSTALL_PREFIX:STRING=/work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn' '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON' '-DCMAKE_INSTALL_RPATH:STRING=/work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn/lib;/work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/gcc-11.2.0/access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn/lib64' '-DCMAKE_PREFIX_PATH:STRING=/work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/none-none/compiler-wrapper-1.0-ln4fjkbeapeb4tzzk2iuplqg4j4xwku7;/work/n01/n01/munday/.spack-1.0.2/opt/spack/linux-sles15-x86_64/none-none/gcc-runtime-11.2.0-dedsb32ucp3n2fhyqm57p5gn6giqr42d;/opt/cray/pe/mpich/8.1.27/ofi/gnu/9.1;/opt/cray/libfabric/1.12.1.2.2.0.0' '-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF' '-DCMAKE_POLICY_DEFAULT_CMP0090:STRING=NEW' '-DCMAKE_FIND_USE_PACKAGE_REGISTRY:BOOL=OFF' '-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON' '-DBUILD_SHARED_LIBS:BOOL=OFF' '-DMOCSY_PRECISION:STRING=2' '/tmp/munday/spack-stage/spack-stage-access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn/spack-src'

1 error found in build log:
  >> 3    CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
     4      CMake 3.22 or higher is required.  You are running version 3.20.4
     5    
     6    
     7    -- Configuring incomplete, errors occurred!

See build log for details:
  /tmp/munday/spack-stage/spack-stage-access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn/spack-build-out.txt

==> Warning: Skipping build of access-generic-tracers-2025.09.000-tbg7gachmqmwstjwxu7ivajmjqudopqz since access-mocsy-2025.07.002-loldyrov64wqfdoucs7asnpjjxqp7rcn failed
==> Error: access-om2-git.2025.09.000=latest-5iccke6jm2b6znvbj27n7wp3kepded43: Package was not installed
==> Error: Installation request failed.  Refer to reported errors for failing package(s).

This was the second time I tried to install, with a spack clean in between to try and get the full error message back. I’m not sure it did. But I shall try using spack to install a more recent version of cmake to resolve that error and then worry about the oasis3-mct ones.

You’re right! I subtracted instead of adding, do it all the time with timezones. Unfortunately I’ve got something else on this week, I’ll see how things go.

Hi Dave,

Can you please provide all the output from the command spack find --external?