Make spack packages for CICE6, MOM6, WWIII, access3-share

[anton-seaice]

Split the existing access-om3-nuopc package into several components, to produce the same result as the access-om3-nuopc package, split into components.

[anton-seaice]

We want to be able to build both the MOM6/CICE6 standalone and access builds.

According to the spack docs, it looks like you can only use git hashes/tags from one repository - see https://spack.readthedocs.io/en/latest/packaging_guide.html#fetching-from-code-repositories

I think this means that we would have one spack package for each component, which points to the access-nri fork, and a seperate spack package (contributed to the upstream spack repo) for the upstream build ?

Should we prefix out packages with access- so we can have different packages for the upstream version in the future.

i.e there is an access-cice package in this repository and a cice package in https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages ?

This seems like duplication, needing two spack packages for each model component ...

[anton-seaice]

As part of this work, I am making a access3-exe package.

The code to produce an executable for access-om3 and access-cm3 are the same ( https://github.com/ESCOMP/CMEPS/blob/main/cesm/driver/esmApp.F90 ), it just needs to be linked to different libraries.

for CM3, currently a lib is made like this:

# make UM library
object_files=""
for file in $ROSE_SUITE_DIR/share/fcm_make/build-atmos/o/*; do
    if [[ $file == *"driver.o" ]]; then
        echo $file
    elif [[ $file == *"um_main.o" ]]; then
        echo $file
    else
        object_files="${object_files} ${file}"
    fi
done

ar -r libum.a $object_files

and linked in through CMake . We should make sure the build is generic to access-om3/cm3/esm3 and avoid using 'om3' as a specific label if possible. ( e.g. in ACCESS-NRI/access3-share#2, change OM3 to Access3). Ill plan to leave the adding of UM to a later issue.