Maths operations on cubes with unstructured grid cause a TypeError in resolve()

[dennissergeev]

🐛 Bug Report

I am using the dev version of iris to work with unstructured grids (LFRic output). The issue I am having is that all maths operations seem to be broken: a TypeError is raised when the maths operation calls resolver.cube(), which in turn invokes the container() method on an auxiliary coordinate with an unexpected keyword bounds (see the full message below). This happens even if the RHS and LHS cubes are the same cube, but it doesn't happen if operations are unary, such as raising the cube to the power.

How To Reproduce

Steps to reproduce the behaviour:

import os

import iris
from iris.experimental.ugrid import PARSE_UGRID_ON_LOAD

test_data_dir = iris.config.TEST_DATA_DIR
src_fn = os.path.join(
    test_data_dir, "NetCDF", "unstructured_grid", "lfric_ngvat_3D_1t_half_level_face_grid_derived_theta_in_w3.nc"
)
with PARSE_UGRID_ON_LOAD.context():
    theta = iris.load_cube(src_fn, "air_potential_temperature")

foo = theta + theta

This results in "TypeError: __init__() got an unexpected keyword argument 'bounds'"

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/tmp/ipykernel_33999/786035974.py in <module>
----> 1 theta + theta

~/mambaforge/envs/ideal_exo/lib/python3.8/site-packages/iris/common/lenient.py in lenient_client_inner(*args, **kwargs)
    122                 """
    123                 with _LENIENT.context(*services, active=_qualname(func)):
--> 124                     result = func(*args, **kwargs)
    125                 return result
    126 

~/mambaforge/envs/ideal_exo/lib/python3.8/site-packages/iris/analysis/maths.py in add(cube, other, dim, in_place)
    231     else:
    232         op = operator.add
--> 233     return _add_subtract_common(
    234         op, "add", cube, other, new_dtype, dim=dim, in_place=in_place
    235     )

~/mambaforge/envs/ideal_exo/lib/python3.8/site-packages/iris/analysis/maths.py in _add_subtract_common(operation_function, operation_name, cube, other, new_dtype, dim, in_place)
    322         raise iris.exceptions.NotYetImplementedError(emsg)
    323 
--> 324     result = _binary_op_common(
    325         operation_function,
    326         operation_name,

~/mambaforge/envs/ideal_exo/lib/python3.8/site-packages/iris/analysis/maths.py in _binary_op_common(operation_function, operation_name, cube, other, new_unit, new_dtype, dim, in_place)
    824         # Insert the resultant data from the maths operation
    825         # within the resolved cube.
--> 826         result = resolver.cube(result.core_data(), in_place=in_place)
    827         _sanitise_metadata(result, new_unit)
    828 

~/mambaforge/envs/ideal_exo/lib/python3.8/site-packages/iris/common/resolve.py in cube(self, data, in_place)
   2344         )
   2345         for item in prepared_aux_coords:
-> 2346             coord = item.container(item.points, bounds=item.bounds)
   2347             coord.metadata = item.metadata.combined
   2348             try:

TypeError: __init__() got an unexpected keyword argument 'bounds'

Expected behaviour

The expected behaviour is obviously that the maths works :)

Environment

• OS & Version: Ubuntu 20.04 LTS
• Iris Version: 3.2.dev0

[bjlittle]

Hey @dennissergeev,

Great to hear from you!

Thanks for taking the time to raise this issue... which means that you're also using the iris.experimental.ugrid functionality, and we're all pretty excited about that :smile:

We're at the odd point where we've extended the iris data model to support unstructured meshes, and we want people to play with it, but we're still in the process of "plumbing-in" this capability to the core of iris.

We've started that journey so that you can at least load and save UGRID, which is reasonably robust now, added a MeshCoord capability (duck typing of AuxCoord but with mesh awareness), touched on various initial mesh support for core methods such as indexing and equality et al, but we've yet to cover a lot of the other core functionality, such as cube arithmetic :disappointed:

We're keen for people to play with the experimental UGRID support and feedback, which is priceless, so thank-you! :beers:

Frustratingly for you, our UGRID support isn't mature enough for your workflow (yet), but your issue is a great reminder to @SciTools/iris-devs that we at least need some minimal and clear documentation for UGRID, targeting iris 3.2 (@lbdreyer release manager). Specifically stating what you can and can't do, and possibly a roadmap/timeline of what core functionality is supported and when other core functionality will be supported.

I know this probably isn't quite the answer that you wanted, but your feedback will most certainly help us priortise how we turn on UGRID capability rolling forwards.

So at this stage, it's pretty much caveat emptor with regards to UGRID, hence the "experimental" title, but don't let that stop you kicking the tyres and feeding back - we really, really do welcome it :+1:

Does that help for now?

[bjlittle]

That said, I'm going to start a UGRID project board so that we can curate and manage community raised UGRID issues along with associated pull-requests... that way we can have some transparency on progress.

I'll also start a UGRID GH Discussions thread as a place for the community to huddle and share on this specific theme.

[zklaus]

Pinging @schlunma since he is interested in unstructured grids.

[bjlittle]

We now have a new UGRID GH Discussions category and UGRID GH Project :tada:

Hopefully this might help us manage and curate all/most things UGRID related... let's see how we roll.

[dennissergeev]

Thanks for the extensive answer @bjlittle! I understand this is an experimental interface and everything is super new, so I am not complaining. I am actually quite impressed that iris allows for working with UGRID at all - it has certainly made my first steps in analysing LFRic data much easier.

I'll keep an eye on the UGRID GH project, and if any low-hanging fruit issues, I'll try to contribute.

[bjlittle]

Thanks for your understanding @dennissergeev ... it's super early days for UGRID support within iris, but we're totally committed to nurturing this capability to the point where it becomes stable and core to iris.

The timeline of when that all happens is a bit vague at the moment, but I know that we're super keen to keep momentum on this effort, as its benefit to the community is a pretty big win.

[pp-mo]

Looks like #4651 will fix this. It seems to work for me, but you'll want to wait until we merge it.

[ESadek-MO]

We believe this was fixed in v3.3, please reopen if this is still a problem. @SciTools/peloton