If we’re generating ancillaries for future use we should make use of the lock file to generate a conda environment, this way the ancillaries can be re-created exactly the same in the future.
If we’re developing ANTS code then it would make sense to install it into a larger environment with Jupyter etc.
I agree with Scott, and I would add that we are planning to release new ANTS versions in a dedicated containerised environment on Gadi (similar to Scott’s ngm one).
However, the main issues remain:
ANTS strict dependency pinning (which makes it very hard to install in an environment together with other packages)
no distributions are available (meaning we have to manage distributions, for example Conda or PyPI, ourselves)
Now that ANTS, as other UKMO tools, are on GitHub, I think it will be easier to have released distributions of ANTS and other tools (e.g., mule, shumlib, ug-ants, etc.) directly connected to their respective GitHub repos and managed in collaboration with the MetOffice.
Thanks @atteggiani, can you please confirm that analysis3-25.08 will remain active (currently throwing warning on load that it will soon be depreciated) until the release of the dedicated seperate ANTS environment? Can you also please confirm which other packages are planned to be included in the seperate ANTS environment?
I’ll defer to @rbeucher on this, as the ACCESS-NRI MED team is managing the analysis3 environments.
There hasn’t been a discussion about this yet.
When the deployment infrastructure is ready (hopefully within a month), I think this could be a good topic to discuss in a Working Group (maybe the Atmosphere one?).
We will not deprecate the environment without providing an alternative for your workflow.
As @atteggiani said, we have flagged the issue with the developers. There have been some changes recently, and we are hopeful we will be able to make the new packages available soon.
Hi all. I’m building a rose/cylc task for the regional Climate model ancillary suite which regrids a MOM6 ocean mask.
My task used to
Load conda/analysis3-25.12 (because it contains the mule dependency)
Use the version of ants installed with ACCESS-rAM3
However, this now fails with the following warnings and errors
module that was compiled using NumPy 1.x cannot be run in
NumPy 2.4.6 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.
..
from mule.packing import wgdos_pack_field, wgdos_unpack_field
File "/g/data/xp65/public/apps/med_conda/envs/analysis3-25.12/lib/python3.11/site-packages/mule/packing.py", line 107, in <module>
raise ImportError(err.args + (msg,))
ImportError: ('numpy.core.multiarray failed to import', 'SHUMlib Packing library found, but failed to import')
The existing ancillary suite definitely still runs with conda/analysis-25.08, but that version was chosen specifically because it was the last environment that shipped with ants (or at least I thought it was- maybe it was mule that was no longer shipped). I suspect ants doesn’t specify its dependencies correctly, which is why the environment managed to concretize with an invalid combination of ants and numpy.
We can deploy a new environment that contains the UKMO modules and xarray- I don’t remember the reason we didn’t include it initially. It feels a bit superfluous to use them in the same task, since they have significantly overlapping functionality- can you load the desired modules for the respective tasks? A newer conda/analysis version for xarray tasks, and the ants package for ants/iris tasks?
Ah yep I forgot about that bit. The most recent versions of the conda environment do contain the iris package, and the ants savers do just wrap the iris savers AFAIK. I’ve been trying to move to iris where possible, as ANTS is not public and people generally do not have visibility of the contents of ants.
I recall that ants has extra functionality when saving ancillary files that iris doesn’t. i.e. iris won’t transfer all the cube metadata to the ancillary header file.
I’ll double check that and get back to you.
Aidan
(Aidan Heerdegen, ACCESS-NRI Release Team Lead)
32
There is nothing stopping someone making a PR to add xarray to the ants environment:
Note that it is pretty lean at the moment, which is a good thing. The more packages you add, the harder it becomes to maintain. Eventually you could end up with an entire analysis environment with ants and a bunch of out-dated packages because ants is so prescriptive about dependencies.
But if xarray is obviously required for ancillary processing workflows (and I can see it might be) then we can add it.
Eventually you could end up with an entire analysis environment with ants and a bunch of out-dated packages because ants is so prescriptive about dependencies.
I don’t think this is necessarily such a bad thing- the main point of the creation of this ants environment was to be able to remove them from our analysis environments, so that everyone that doesn’t have to deal with UM nonsense are not held back by the people that do have to deal with it. I’m on board with adding xarray to this environment.