Retrieve_ozone job failing

Earth System Coupled Model
1

Hi all,

I’m trying to run a historical ACCESS-CM2 suite and I’m getting an error in the retrieve_ozone job, which I think is related to the new Conda environment conda/analysis3-26.03.

This is the error:

Traceback (most recent call last):
File “/g/data/access/projects/access/apps/pythonlib/umfile_utils/access_cm2/um_fields_subset.py”, line 68, in 
f = umfile.UMFile(ifile)
^^^^^^^^^^^^^^^^^^^^
File “/g/data/access/projects/access/apps/pythonlib/umfile_utils/access_cm2/umfile.py”, line 27, in **init**
self.determine_file_type()
File “/g/data/access/projects/access/apps/pythonlib/umfile_utils/access_cm2/umfile.py”, line 68, in determine_file_type
h = np.fromstring(s,np.int64).newbyteorder(endian)
^^^^^^^^^^^^^^^^^^^^^^^^^

ValueError: The binary mode of fromstring is removed, use frombuffer instead
Traceback (most recent call last):
File “/g/data/access/projects/access/apps/pythonlib/umfile_utils/access_cm2/um2netcdf4.py”, line 4, in 
import cf_units, cftime, mule
ModuleNotFoundError: No module named ‘mule’

It’s similar to the issue described here.

I tried adding

module use /g/data/xp65/public/modules
module load conda/analysis3-25.08

to the pre-script of [[retrieve_ozone]] in ozone.rc, but the latest Conda environment is still loaded after that.

If I remove

module use ~access/modules
module load pythonlib/umfile_utils/access_cm2_xp65

from the pre-script, the job just times out.

I last ran the suite late last year.

Can the /g/data/access/modules/pythonlib/umfile_utils/access_cm2_xp65 file be edited to load an older Conda environment instead? Or is there another workaround I could try?

Thanks,
Zoe

2

Easiest temporary workaround would be to make a temporary copy of that modulefile and specify conda/analysis3-25.08 in the module load, then load that. I’ll ping someone with admin rights in /g/data/access to make that fix in the original.

3

Should now be fixed- if problems persist, please ping me and I’ll dig a bit deeper.