Is your feature request related to a problem? Please describe.
In the CMIP context, CMORisation is often performed on the native model grid. For ocean variables, however, the use of tripolar grids introduces additional challenges for downstream evaluation workflows, as the data frequently needs to be regridded before it can be analysed consistently.
This can create difficulties for users working with tools such as ESMValTool and ILAMB/IOMB, particularly when handling:
- curvilinear coordinates,
- ocean masks and bounds,
- conservative remapping,
- and general preprocessing complexity.
While ESMValTool already provides some regridding capabilities, users often end up implementing custom preprocessing workflows, which can lead to duplicated effort and inconsistent evaluation pipelines.
Describe the feature you'd like
Add optional support in ACCESS-MOPPy to generate CMORised outputs directly on a user-defined non-native target grid through an integrated regridding workflow.
The goal would not be to replace native-grid CMIP archival outputs, but rather to support the creation of evaluation-ready datasets that can be used more easily with tools such as ESMValTool, ILAMB, notebooks, or rapid evaluation workflows.
Potential functionality could include:
- specifying a target grid during CMORisation,
- choosing the regridding method (bilinear, conservative, nearest-neighbour, etc.),
- automatic handling of masks and bounds,
- provenance tracking of the original grid and regridding configuration,
- compatibility with HPC and Dask-based workflows.
Example API ideas:
mop.cmorise(..., target_grid="1x1")
Describe alternatives you've considered
- Performing regridding downstream in evaluation tools such as ESMValTool.
- Using standalone preprocessing tools such as CDO, xESMF, or Iris before running diagnostics.
- Keeping regridding entirely within user notebooks or custom workflows.
While these approaches work, they often increase workflow complexity and can lead to inconsistent preprocessing choices across users and projects.
Additional context
This feature could fit naturally within the ACCESS-MOPPy “Live/Lite CMORisation” workflow philosophy by helping users move from:
raw model output → lightweight CMORisation → evaluation-ready datasets.
It may also be particularly useful for Rapid Evaluation Framework (REF)-style workflows where reducing preprocessing overhead is important.
Is your feature request related to a problem? Please describe.
In the CMIP context, CMORisation is often performed on the native model grid. For ocean variables, however, the use of tripolar grids introduces additional challenges for downstream evaluation workflows, as the data frequently needs to be regridded before it can be analysed consistently.
This can create difficulties for users working with tools such as ESMValTool and ILAMB/IOMB, particularly when handling:
While ESMValTool already provides some regridding capabilities, users often end up implementing custom preprocessing workflows, which can lead to duplicated effort and inconsistent evaluation pipelines.
Describe the feature you'd like
Add optional support in ACCESS-MOPPy to generate CMORised outputs directly on a user-defined non-native target grid through an integrated regridding workflow.
The goal would not be to replace native-grid CMIP archival outputs, but rather to support the creation of evaluation-ready datasets that can be used more easily with tools such as ESMValTool, ILAMB, notebooks, or rapid evaluation workflows.
Potential functionality could include:
Example API ideas:
Describe alternatives you've considered
While these approaches work, they often increase workflow complexity and can lead to inconsistent preprocessing choices across users and projects.
Additional context
This feature could fit naturally within the ACCESS-MOPPy “Live/Lite CMORisation” workflow philosophy by helping users move from:
raw model output → lightweight CMORisation → evaluation-ready datasets.
It may also be particularly useful for Rapid Evaluation Framework (REF)-style workflows where reducing preprocessing overhead is important.