Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dennissergeev opened this issue Dec 8, 2021 · 8 comments

Comments

@dennissergeev
Copy link
Contributor

馃悰 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
Copy link
Member

bjlittle commented Dec 15, 2021

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 馃槃

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 馃槥

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

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 馃憤

Does that help for now?

@bjlittle
Copy link
Member

bjlittle commented Dec 15, 2021

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
Copy link
Contributor

zklaus commented Dec 15, 2021

Pinging @schlunma since he is interested in unstructured grids.

@bjlittle bjlittle added this to Backlog in UGRID via automation Dec 15, 2021
@bjlittle
Copy link
Member

bjlittle commented Dec 15, 2021

We now have a new UGRID GH Discussions category and UGRID GH Project 馃帀

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

@dennissergeev
Copy link
Contributor Author

dennissergeev commented Dec 15, 2021

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
Copy link
Member

bjlittle commented Dec 15, 2021

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
Copy link
Member

pp-mo commented Mar 29, 2022

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

@ESadek-MO
Copy link
Contributor

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

UGRID automation moved this from Backlog to Done May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
UGRID
Done
Development

No branches or pull requests

7 participants