Thanks Aidan, so… let’s say if I wanted to recompile ACCESS-OM2 myself from this repo, could I make my own exe with extra traceback flags?
The easiest way, and what we’re doing with a lot of the model development work is to use the build machinery to do it all for you by creating a pull request with the modifications you need
However this requires write access to the ACCESS-OM2 repo, as you need to make a branch there for the pull request to do it’s magic. If you’re interested we can certainly add you as a collaborator.
The other option is to build the model yourself on gadi
Note that you don’t need to create a development package for MOM5 in this instance, as all the changes you want to make will be in the spack.yaml, so at the environment level.
Regardless of which way you choose to go you will need to add some FFLAGS variables to the spack.yaml.
This is a different model, but you can see the pattern of how to add additional build flags in the spack.yaml
You can add them to whatever dependencies you want, just MOM, or MOM, CICE and netcdf, whatever. Spack will build it for you.
1 Like
Thanks Aidan. I may try the “build on Gadi” approach next week. Great to know the instructions are there for DIY compiling.
1 Like
Feel free to try both approaches to see compare which use might suit each one.
DIY building is good for checking rapid code changes. The deployment auto-build approach is good for minimal effort, but also reproducibility and checking your work, and particularly for sharing with others. It creates a pre-release build that anyone can use with simple module use/module load steps, and it can stay deployed in prerelease for as long as it is useful.