Add pycmor to CMORization tools

[siligam]

Summary

Adds a new CMORization tools section to docs/cmor_and_mip_tables.md listing pycmor, a Python package developed at the Alfred Wegener Institute (AWI) that provides a high-level, declarative pipeline for converting Earth system model output into CMOR-compliant NetCDF for CMIP6 and CMIP7 submission.

Why this section: The page currently covers the CMOR library itself and MIP tables, but there is no listing of community tools built on top of CMOR. A "CMORization tools" section makes it easier for modelling centres to discover Python-level wrappers that reduce the friction of using CMOR directly.

About pycmor:

• Plugin-based pipeline: model-specific plugins for FESOM2, OpenIFS, PISM; extensible to any ESM
• CMIP7-ready: actively tracking CMIP7 data request and Controlled Vocabularies
• HPC-native: dask/SLURM parallelism for large multi-variable datasets
• MIT license, pip-installable (pip install py-cmor)
• Docs: https://pymor.readthedocs.io
• DOI: https://doi.org/10.5281/zenodo.15530131

Happy to add other CMORization tools to this section if others are known to the community.

[taylor13]

This is a good suggestion. I think we should encourage others to provide tools to help in preparing model output, but before advertising them, I think we should consider whether they:

1. Correctly cmorize CMIP7 output (at least).
2. Can keep up with the evolving input files (e.g., data request, CMOR tables, CVs)
3. Offer ongoing support for users.
4. Are in the public domain.

It would also be helpful to clearly state how they have been tested:

1. Does output from all variables pass the QC/QA. checks and the CF checker?
2. Which/how many modeling groups have relied on the software to produce CMIP output?

And also what specific advantages do the tools offer relative to, say, the CMOR library.

Finally, as I understand it, pycmor reproduces the some/all? capabilities of CMOR3. Could you say why pycmor is easier to use? Are there any disadvantages you know of?

[siligam]

Hi Karl,

Thanks for the quick and thoughtful response — we appreciate you engaging with this constructively rather than just waving it through or shutting it down.

The bar you've laid out (correctness on CMIP7 output, ability to track the moving data request/tables/CVs, ongoing support, open licensing, QC evidence, adoption breadth, and an honest comparison to CMOR) is exactly the right one for anything we'd want WCRP to point modelling centres at. So in that spirit, here's where things actually stand, rather than how we'd like them to sound:

• License: MIT, openly developed on GitHub. That part's solid.
• CMIP7 correctness: still under active development, not a finished, validated capability. Our own test suite currently marks the CMIP7 path as not-yet-implemented for several core cases.
• Adoption: the only real production use case so far is our own CMIP7 submission work at AWI (FESOM2 / AWI-ESM-3), and even that is still evolving on development branches rather than fully merged and tested. We don't yet have a second modelling group with a working CMIP7 run.
• QC evidence: the most concrete external check we've had is from DKRZ, who ran our output through their cmip7repack tool and caught a real compliance bug — lat/lon coordinates written as float32 instead of the required float64 (Bug: lat/lon coordinates written as float32 instead of required float64 esm-tools/pycmor#269). A fix is in progress (fix: cast lat/lon coordinates to float64 at CMOR writer level esm-tools/pycmor#270) but not yet merged. We see that as a healthy sign of real engagement, but it also means we're not done.
• Support: best-effort from a small team right now, not a resourced commitment we can promise to a whole community.

Given that, we don't think this is the right time to ask WCRP to list pycmor as a recommended CMORization tool. We'd like to withdraw this PR for now and come back once we can back a listing with broader validation and a real support commitment, rather than ask you to vouch for something that's still proving itself.

Thanks again for pushing on this — it's a useful gut-check.

[durack1]

If we're going down the path of listing packages, may as well be comprehensive. I collated a bunch of CMOR wrappers in Table D1 (see here), and collated a couple more post-submission, including PyCMOR - once this paper is updated, can refer to the complete list

[siligam]

Thanks for the pointer to the comprehensive table — that's a great reference for a future, broader listing effort.

Closing this for now per the above; we'll revisit listing pycmor once it has stronger validation and a real support commitment behind it.

[durack1]

To be fair, not all the software/tools in the paper/table have broad support for users not in their community banked in, but these are all efforts that build on the CMOR core functionality, or replicate it, in the case of XIOS for IPSL/CNRM modelling configurations, so happy to include pymor plus others, if they exist

[matthew-mizielinski]

Hi all, @siligam I would encourage you to put in a PR to WCRP-CMIP/CMIP7-guidance to link to information on py-cmor -- we'll just need to ensure there is appropriate information about the level of support.

[mandresm]

Hi @matthew-mizielinski and all. We'll discuss this internally and open the PR. I agree the important part is to be clear about the status and level of support. As the level of support and completeness of the tool changes in time we will have to update also the CMIP7-guidance.