UM partnership Mule repository and working practices

Atmosphere Unified Model
, ,
1

The MOSRS repository for Mule and its NCI mirror are:

$ fcm kp | grep mule
location{primary}[mule.x] = https://code.metoffice.gov.uk/svn/um/mule
location{primary}[mule.xm] = file:///g/data/ki32/mosrs/um/mule

The Mule working practices as documented by the UK Met Office are at https://code.metoffice.gov.uk/trac/um/wiki/working_practices_mule

The next Mule milestone and its assoicated Trac tickets are at https://code.metoffice.gov.uk/trac/um/query?group=status&milestone=Mule+-+next+version

2

See also the note at https://accessdev.nci.org.au/trac/wiki/access/BomAccessDocumentation/bom-conda which says:

It looks like some pythonlib/* modulefiles have been migrated to Gadi contrary to the impression that NCI will not support them

  • For example, there is the installation, pythonlib/mule/2019.01.1 which contains Mule-related tools. nwptools_py2/201911 also contains Mule-related tools.
  • In the interest of reducing the overhead resulting from duplication we should coordinate with CSIRO and CLEX in managing these tools. Perhaps Milton should initiate a discussion with Martin and Scott in early 2020

While I was at NCI, I helped to catalogue the pythonlib and related /g/data/access modules, including pythonlib/mule and pythonlib/umfile_utils.

3

See also https://github.com/metomi/mule for a less up-to-date public repo.

Conda recipe at https://github.com/coecms/conda-skeletons/tree/master/mule (version 2022.07, used in hh5 conda) and https://git.nci.org.au/bom/ngm/conda-pkgs/conda-pkgs/-/tree/master/mule (version 2023.08, used in /g/data/access/ngm modules)

The bare pythonlib modules should not be used as they can have dependency conflicts, use a conda environment instead.

1 Like