This repository contains several ACCESS-OM3 configurations using the following components:
- MOM6 ocean model
- CICE sea ice model
- WW3 wave model
- DATM atmosphere data model
- DROF runoff data model
All the configurations use the payu workflow management tool.
Each configuration is stored as a git branch. Most of the branches are named according to the following naming scheme:
{nominal_resolution}deg_{forcing_data}_{forcing_method}
Additional required information, like if the configuration includes biogeochemistry, is appended to the name.
Currently the following configurations are available:
Note that the main
branch does not store any configuration, only some documentation.
The first thing to do is to clone this repository. Although it is possible to directly clone the repository from this repository, it is better to use a fork instead. This will allow you to push any changes you make to the configuration, as well as use the payu run log to keep track of your experiment in your fork on GitHub. Detailed instructions about how to set up a fork can be found here.
Once you have set up your fork, we recommend cloning to a directory with a unique name that reflects what you wish to run. This could simply be the name of the configuration you plan to run, but the more detailed the name is, the less likely a namespace clash will happen.
Finally, one needs to checkout the branch corresponding to the desired configuration. It is then good practice to start a new branch with the same name as your directory so you can use git to easily see how your run configuration differs from the original.
Here is an step-by-step example of how to set up a dev-1deg_jra55do_ryf
experiment
(called my_1deg_jra55do_ryf_experiment_name
) after setting up your fork:
git clone git@github.com:<username>/access-om3-wav-configs.git my_1deg_jra55do_ryf_experiment_name
cd my_1deg_jra55do_ryf_experiment_name
git checkout dev-1deg_jra55do_ryf
git checkout -b my_1deg_jra55do_ryf_experiment_name
Here <username>
should be your GitHub user name.
By default, the payu run log is turned off, but you should turn it on so that
your configuration settings will be recorded as the run proceeds. Simply edit
the config.yaml
file and change the following line:
runlog: false
to
runlog: true
See this section of the quick start instructions in the ACCESS-OM3 wiki.
See this section of the quick start instructions in the ACCESS-OM3 wiki.
We welcome contributions from users of these configurations. If you make a
configuration improvement which you think should be included in the COSIMA
repository, push it to your fork and then do a pull request from the relevant
branch in your fork to the branch it originated from in the COSIMA repository
(not main
).
This repository contains a user-dispatchable workflow (minimum Write
role required) for the generation of reproducibility checksums on a given Config Branch. The workflow requires sign off from @ACCESS-NRI/ocean to run on Gadi.
Workflow inputs :
Input | Type | Required | Default | Description | Example | Notes |
---|---|---|---|---|---|---|
config-branch-name |
string |
true |
N/A | The configuration branch that will be run that will generate the checksums | dev-025deg_jra55do_ryf |
This can be any branch - not just release or dev branches |
commit-checksums |
boolean |
true |
false |
Whether to commit the checksums to the target branch once generated | true |
If unchecked, the checksums are still accessible as a workflow run artifact |
committed-checksum-location |
string |
false |
./testing/checksum |
If checksums are being committed: Where in the repository the generated checksums should be committed | ./some/dir |
Requires the path starting with . |
committed-checksum-tag-version |
string |
false |
N/A | If checksums are being committed: An optional initial version for the committed checksums as a git tag of the form {config-branch-name}-{version} |
1.0 |
If left blank, no tag will be added |
This is the config/ci.json
configuration file for specifying different test markers, or test versions based on type of the test to run, and the name of the git branch or tag. The different types of test are defined as:
scheduled
: Scheduled monthly reproducibility tests. The keys under these tests represent released config tags to run scheduled checks on.reproducibility
: Reproducibility tests that are run as part of pull requests. The keys under these tests represent the target branches into which pull requests are being merged.qa
- Quick quality assurance tests that are run as part of pull requests. The keys under these tests represent the target branches into which pull requests are being merged.
The configuration properties needed to run the tests are:
Name | Type | Description | Example |
---|---|---|---|
markers | string |
Markers used for the pytest checks, in the python format | checksum |
model-config-tests-version | string |
The version of the model-config-tests | 0.0.1 |
python-version | string |
The python version used to create test virtual environment on Github hosted tests | 3.11.0 |
payu-version | string |
The Payu version used to run the model | 1.1.5 |
As most of the tests use the same test and python versions, and similar markers, there are two levels of defaults. There's a default at test type level which is useful for defining test markers - this selects certain pytests to run in model-config-tests
. There is an outer global default, which is used if a property is not defined for a given branch/tag, and it is not defined for the test default. The parse-ci-config
action applies the fall-back default logic. For more information on using this action see ACCESS-NRI/model-config-tests
.