Skip to content

Commit c1669ed

Browse files
committed
Improve documentation
1 parent a35d65b commit c1669ed

File tree

3 files changed

+217
-24
lines changed

3 files changed

+217
-24
lines changed

.zenodo.json

Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
{
2+
"creators": [
3+
{
4+
"orcid": "0000-0003-3891-5444",
5+
"affiliation": "ACCESS-NRI",
6+
"name": "Beucher, Romain"
7+
}
8+
],
9+
"contributors": [
10+
{
11+
"name": "Paola Petrellui",
12+
"affiliation": "University of Tasmania",
13+
"orcid": "0000-0002-0164-5105",
14+
"type": "Version 1 developer"
15+
},
16+
{
17+
"name": "Samuel Green",
18+
"affiliation": "ARC Centre of Excellence for the Weather of the 21st Century",
19+
"orcid": "0000-0003-1129-4676",
20+
"type": "Version 1 developer"
21+
},
22+
{
23+
"name": "Chloe Mackallah",
24+
"affiliation": "CSIRO",
25+
"orcid": "0000-0003-4989-5530",
26+
"type": "APP4 developer"
27+
}
28+
],
29+
30+
"license": "Apache-2.0",
31+
32+
"title": "ACCESS-MOPPeR",
33+
34+
"keywords": ["Climate", "Science", "Model Evaluation", "CMOR", "CMIP", "ACCESS", "ACCESS-NRI", "NCI"],
35+
36+
"communities": [
37+
{"identifier": "access-nri"}
38+
]
39+
}

README.md

Lines changed: 44 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
1-
# ACCESS-MOPPeR v2.1.0a (Alpha Version)
1+
# ACCESS Model Output Post-Processor (ACCESS-MOPPeR) v2.1.0a (Alpha Version)
22

33
## Overview
4-
ACCESS-MOPPeR v2.0.0a is a CMORisation tool designed to post-process ACCESS model output. This version represents a significant rewrite of the original MOPPeR, focusing on usability rather than raw performance. It introduces a more flexible and user-friendly Python API that can be integrated into Jupyter notebooks and other workflows.
4+
ACCESS-MOPPeR v2.1.0a is a CMORisation tool designed to post-process ACCESS model output. This version represents a significant rewrite of the original MOPPeR, focusing on usability rather than raw performance. It introduces a more flexible and user-friendly Python API that can be integrated into Jupyter notebooks and other workflows.
55

66
ACCESS-MOPPeR allows for targeted CMORisation of individual variables and is specifically designed to support the ACCESS-ESM1.6 configuration prepared for CMIP7 FastTrack. However, ocean variable support remains limited in this alpha release.
77

@@ -15,23 +15,52 @@ ACCESS-MOPPeR allows for targeted CMORisation of individual variables and is spe
1515

1616
## Current Limitations
1717
- **Alpha Version**: Intended for evaluation purposes only; not recommended for data publication.
18-
- **Limited Ocean Variable Support**: Further development is needed to support ocean-related variables fully.
18+
19+
> **⚠️ Variable Mapping Under Review**
20+
>
21+
> We are currently reviewing the mapping of ACCESS variables to their CMIP6 and CMIP7 equivalents. Some variables that require derivation may not be available yet, or their calculation may need further verification.
22+
> **If you notice any major issues or missing variables, please submit an issue!**
23+
1924

2025
## Background
21-
ACCESS-MOPPeR builds upon the original APP4 and MOPPeR frameworks, which were initially developed for CMIP5 and later extended for CMIP6. These tools leveraged CMOR3 and CMIP6 data request files to produce CF-compliant datasets aligned with ESGF standards. MOPPeR introduced the **mopdb** tool, allowing users to create custom mappings and CMOR table definitions.
26+
ACCESS-MOPPeR v2 is a complete rewrite of the original APP4 and MOPPeR frameworks. Unlike previous versions, it does **not** depend on CMOR; instead, it leverages modern Python libraries such as **xarray** and **dask** for efficient processing of NETCDF files. This approach streamlines the workflow, improves flexibility, and enhances integration with contemporary data science tools.
27+
28+
While retaining the core concepts of "custom" and "cmip" modes, ACCESS-MOPPeR v2 unifies these workflows within a single configuration file, focusing on usability and extensibility for current and future CMIP projects.
29+
30+
---
31+
32+
## Installation
33+
34+
35+
```sh
36+
pip install numpy pandas xarray netCDF4 cftime dask pyyaml tqdm requests
37+
pip install .
38+
```
39+
40+
---
41+
42+
## Documentation
43+
44+
See the [Getting Started notebook](notebooks/Getting_started.ipynb) and the [docs](docs/) folder for detailed usage and API documentation.
45+
46+
---
47+
48+
## Testing
49+
50+
To run tests:
51+
52+
```sh
53+
pytest
54+
```
55+
56+
---
2257

23-
This rewrite retains key features of the original MOPPeR while enhancing usability. The differentiation between "custom" and "cmip" modes remains, but both modes now follow a unified workflow defined in a single configuration file.
58+
## License
2459

25-
## Usage
26-
ACCESS-MOPPeR v2.0.0a is best suited for users interested in evaluating outputs from ACCESS-ESM1.6 development releases. Full documentation is not available yet.
27-
Please refer to the [Getting Started Notebook](https://github.com/ACCESS-NRI/ACCESS-MOPPeR/blob/v2/notebooks/Getting_started.ipynb):
60+
ACCESS-MOPPeR is licensed under the Apache-2.0 License.
2861

29-
## Future Development
30-
- **Optimised Multi-CPU Execution**: Parallel processing support will be introduced in later versions.
31-
- **Enhanced Ocean Variable Support**: Expansion of CMORisation capabilities for ocean-related data.
32-
- **Expanded CMORisation Standards**: Continued flexibility in defining custom post-processing standards beyond CMIP6.
62+
---
3363

34-
## Disclaimer
35-
This is an **alpha release** and should not be used for official data publications. Users should expect potential changes in future versions that may affect workflow compatibility.
64+
## Contact
3665

37-
For feedback or issues, please submit your contributions via the project's repository or contact the development team.
66+
Author: Romain Beucher

notebooks/Getting_started.ipynb

Lines changed: 134 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,17 @@
55
"id": "c042f571-90e9-4160-ae53-bdbc5a165525",
66
"metadata": {},
77
"source": [
8-
"# ACCESS-MOPPeR Getting Started"
8+
"# ACCESS-MOPPeR Getting Started\n",
9+
"\n",
10+
"Welcome to the ACCESS-MOPPeR Getting Started guide!\n",
11+
"\n",
12+
"This notebook will walk you through the initial setup and basic usage of ACCESS-MOPPeR, a tool designed to post-process ACCESS model output and produce CMIP-compliant datasets. You’ll learn how to configure your environment, prepare your data, and run the CMORisation workflow using both the Python API and Dask for scalable processing.\n",
13+
"\n",
14+
"By following this guide, you’ll be able to:\n",
15+
"- Set up your user configuration\n",
16+
"- Select input data files\n",
17+
"- Run the CMORisation process for selected variables\n",
18+
"- Inspect and save the processed output\n"
919
]
1020
},
1121
{
@@ -28,7 +38,7 @@
2838
},
2939
{
3040
"cell_type": "code",
31-
"execution_count": 1,
41+
"execution_count": null,
3242
"id": "80dbbe95-35ea-43d1-a1a0-cea79082b2eb",
3343
"metadata": {},
3444
"outputs": [
@@ -46,13 +56,32 @@
4656
}
4757
],
4858
"source": [
49-
"from access_mopper import ACCESS_ESM_CMORiser\n",
50-
"import dask.distributed as dask"
59+
"from access_mopper import ACCESS_ESM_CMORiser"
60+
]
61+
},
62+
{
63+
"cell_type": "markdown",
64+
"id": "eae38f8c",
65+
"metadata": {},
66+
"source": [
67+
"## Dask support\n",
68+
"\n",
69+
"ACCESS-MOPPeR supports Dask for parallel processing, which can significantly speed up the CMORisation workflow, especially when working with large datasets. To use Dask with ACCESS-MOPPeR, you can create a Dask client it will be used to manage the distributed computation. This allows you to take advantage of multiple CPU cores or even a cluster of machines, depending on your setup.\n",
70+
"You can configure the Dask client to use a specific number of threads per worker, which can help optimize performance based on your hardware and the size of the datasets you are processing.\n",
71+
"\n",
72+
"Here's an example of how to set up a Dask client:\n",
73+
"\n",
74+
"```python\n",
75+
"import dask.distributed as dask\n",
76+
"\n",
77+
"client = dask.Client(threads_per_worker=1)\n",
78+
"client\n",
79+
"```"
5180
]
5281
},
5382
{
5483
"cell_type": "code",
55-
"execution_count": 2,
84+
"execution_count": null,
5685
"id": "9000d152-d67c-49ad-a648-025a0808cfe8",
5786
"metadata": {},
5887
"outputs": [
@@ -734,21 +763,50 @@
734763
}
735764
],
736765
"source": [
766+
"import dask.distributed as dask\n",
767+
"\n",
737768
"client = dask.Client(threads_per_worker = 1)\n",
738769
"client"
739770
]
740771
},
772+
{
773+
"cell_type": "markdown",
774+
"id": "d14ad618",
775+
"metadata": {},
776+
"source": [
777+
"## Data selection\n",
778+
"\n",
779+
"The `ACCESS_ESM_CMORiser` class (described in detail below) takes as input a list of paths to NetCDF files containing the raw model output variables to be CMORised. The CMORiser does **not** assume any specific folder structure, DRS (Data Reference Syntax), or file naming convention. It is intentionally left to the user to ensure that the provided files contain the original variables required for CMORisation.\n",
780+
"\n",
781+
"This design is intentional: ACCESS-NRI plans to integrate ACCESS-MOPPeR into extended workflows that leverage the [ACCESS-NRI Intake Catalog](https://github.com/ACCESS-NRI/access-nri-intake-catalog) or evaluation frameworks such as [ESMValTool](https://www.esmvaltool.org/) and [ILAMB](https://www.ilamb.org/). By decoupling file selection from the CMORiser, ACCESS-MOPPeR can be flexibly used in a variety of data processing and evaluation pipelines."
782+
]
783+
},
741784
{
742785
"cell_type": "code",
743-
"execution_count": 3,
786+
"execution_count": null,
744787
"id": "f49fd1d4-dcb6-47a8-9d4a-731a7ca1ea0d",
745788
"metadata": {},
746789
"outputs": [],
747790
"source": [
791+
"# Here we use netcdf file from a raw ACCESS-ESM run.\n",
748792
"import glob\n",
749793
"files = glob.glob(\"../../Test_data/esm1-6/atmosphere/aiihca.pa-0961*_mon.nc\")"
750794
]
751795
},
796+
{
797+
"cell_type": "markdown",
798+
"id": "d458b955",
799+
"metadata": {},
800+
"source": [
801+
"### Parent experiment information\n",
802+
"\n",
803+
"In CMIP workflows, providing parent experiment information is required for proper data provenance and traceability. This metadata describes the relationship between your experiment and its parent (for example, a historical run branching from a piControl simulation), and is essential for CMIP data publication and compliance.\n",
804+
"\n",
805+
"However, for some applications—such as when using ACCESS-MOPPeR to interact with evaluation frameworks like [ESMValTool](https://www.esmvaltool.org/) or [ILAMB](https://www.ilamb.org/)—strict CMIP compliance is not always necessary. In these cases, you may choose to skip providing parent experiment information to simplify the workflow.\n",
806+
"\n",
807+
"If you choose to skip this step, ACCESS-MOPPeR will issue a warning to let you know that, if you write the output to disk, the resulting file may not be compatible with CMIP requirements for publication. This flexibility allows you to use ACCESS-MOPPeR for rapid evaluation and prototyping, while still supporting full CMIP compliance when needed."
808+
]
809+
},
752810
{
753811
"cell_type": "code",
754812
"execution_count": 4,
@@ -769,9 +827,27 @@
769827
"}"
770828
]
771829
},
830+
{
831+
"cell_type": "markdown",
832+
"id": "68b05b80",
833+
"metadata": {
834+
"vscode": {
835+
"languageId": "markdown"
836+
}
837+
},
838+
"source": [
839+
"## Set up the CMORiser for CMORisation\n",
840+
"\n",
841+
"To begin the CMORisation process, you need to create an instance of the `ACCESS_ESM_CMORiser` class. This class requires several key parameters, including the list of input NetCDF files and metadata describing your experiment.\n",
842+
"\n",
843+
"A crucial parameter is the `compound_name`, which should be specified using the full CMIP convention: `table.variable` (for example, `Amon.rsds`). This format uniquely identifies the variable, its frequency (e.g., monthly, daily), and the associated CMIP table, ensuring that all requirements for grids and metadata are correctly handled. Using the full compound name helps avoid ambiguity and guarantees that the CMORiser applies the correct standards for each variable.\n",
844+
"\n",
845+
"You can also provide additional metadata such as `experiment_id`, `source_id`, `variant_label`, and `grid_label` to ensure your output is CMIP-compliant. Optionally, you may include parent experiment information for full provenance tracking."
846+
]
847+
},
772848
{
773849
"cell_type": "code",
774-
"execution_count": 5,
850+
"execution_count": null,
775851
"id": "0e54cf4e-b707-4128-aa93-23bb9cf684d3",
776852
"metadata": {},
777853
"outputs": [],
@@ -784,19 +860,52 @@
784860
" variant_label=\"r1i1p1f1\",\n",
785861
" grid_label=\"gn\",\n",
786862
" activity_id=\"CMIP\",\n",
787-
" parent_info=parent_experiment_config)"
863+
" parent_info=parent_experiment_config # <-- This is optional, can be skipped if not needed\n",
864+
" )"
865+
]
866+
},
867+
{
868+
"cell_type": "markdown",
869+
"id": "de6be45d",
870+
"metadata": {
871+
"vscode": {
872+
"languageId": "markdown"
873+
}
874+
},
875+
"source": [
876+
"## Running the CMORiser\n",
877+
"\n",
878+
"To start the CMORisation process, simply call the `run()` method on your `cmoriser` instance as shown below. This step may take some time, especially if you are processing a large number of files.\n",
879+
"\n",
880+
"We recommend using the [dask-labextension](https://github.com/dask/dask-labextension) with JupyterLab to monitor the progress of your computation. The extension provides a convenient dashboard to track task progress and resource usage directly within your notebook interface.\n"
788881
]
789882
},
790883
{
791884
"cell_type": "code",
792-
"execution_count": 6,
885+
"execution_count": null,
793886
"id": "5e6c9e48-9dc0-42ab-a396-6bcf7b57cb42",
794887
"metadata": {},
795888
"outputs": [],
796889
"source": [
797890
"cmoriser.run()"
798891
]
799892
},
893+
{
894+
"cell_type": "markdown",
895+
"id": "c1fade88",
896+
"metadata": {
897+
"vscode": {
898+
"languageId": "markdown"
899+
}
900+
},
901+
"source": [
902+
"### In-memory processing with xarray and Dask\n",
903+
"\n",
904+
"The CMORisation workflow processes data entirely in memory using `xarray` and Dask. This approach enables efficient parallel computation and flexible data manipulation, but requires that your system has enough memory to handle the size of your dataset. \n",
905+
"\n",
906+
"Once the CMORisation is complete, you can access the resulting dataset by calling the `to_dataset()` method on your `cmoriser` instance (see below). The returned object is a standard xarray dataset, which means you can slice, analyze, or further process the data using familiar xarray operations."
907+
]
908+
},
800909
{
801910
"cell_type": "code",
802911
"execution_count": 7,
@@ -1677,6 +1786,22 @@
16771786
"ds"
16781787
]
16791788
},
1789+
{
1790+
"cell_type": "markdown",
1791+
"id": "f2a97420",
1792+
"metadata": {
1793+
"vscode": {
1794+
"languageId": "markdown"
1795+
}
1796+
},
1797+
"source": [
1798+
"### Writing the output to a NetCDF file\n",
1799+
"\n",
1800+
"To save your CMORised data to disk, use the `write()` method of the `cmoriser` instance. This will create a NetCDF file with all attributes set according to the CMIP Controlled Vocabulary, ensuring compliance with CMIP metadata standards.\n",
1801+
"\n",
1802+
"After writing the file, we recommend validating it using [PrePARE](https://github.com/PCMDI/cmor/tree/master/PrePARE), a tool provided by PCMDI to check the conformity of CMIP files. PrePARE will help you identify any issues with metadata or file structure before publication or further analysis."
1803+
]
1804+
},
16801805
{
16811806
"cell_type": "code",
16821807
"execution_count": 9,

0 commit comments

Comments
 (0)