iris
iris copied to clipboard
SciTools
Iris bridge to GeoVista
User interest in geovista seems to be blossoming right now. We have various resources showing how to link to it from Iris, e.g. the Mesh plotting section + example. Plus the region extraction example And in future we might extend this.
Likewise we have produced various demo notebooks containing similar code content.
But there's a lot of duplicated code + boilerplate making the link between cubes and PyVista polydata. So there is a really useful opportunity to provide an "iris geovista bridge" module.
However it's not clear where this would live, and where it should get tested. It should not add to the the core dependencies, or the C.I. testing costs. It could be a partner package, like iris-grib or iris-esmf-regrid. The idea of a plugin architecture might also have legs.
The idea of a plugin architecture might also have legs.
I personally think proliferation of plugin packages is ill fitted to our situation.
The two arguments in favour (that I'm aware of):
- Aids innovation in large projects because the plugins can be managed by non-core developers. Not really applicable here.
- Makes it easier to introduce dependencies not required by the core package This isn't actually true. Xarray (and others I'm sure) have demonstrated that you can have a very cut-down recipe, with errors/warnings if a user tries to invoke an optional dependency without it being installed.
Arguments against:
- Doubling up on repo management - dependabot, lock-files, dev permissions etcetera
- A user has to understand the structure so they can raise the issue in the right place
Discussed during refinement for Iris 3.8.
Features
The MVP bridge would constitute two operations as previously noted by @pp-mo:
- Conversion from
CubetoPolyData - Indexing a
CubeusingPolyDataindices. Could we stick the whole operation in a function so the user didn't need to learn GeoVista/PyVista? - We do NOT expect a need for conversion from
PolyDatatoCube
Possible dependency problems
To avoid getting bogged down in concerns about dependencies, we recommend giving it a try and seeing what happens:
- Introduce the bridge features in
iris.experimental- can back out if we run into trouble - Include GeoVista as an optional Iris dependency
- Acknowledge that this means making the testing / development environment larger
- Raise a helpful warning if a user tries to invoke something requiring GeoVista but it is not installed
- Schedule a team review in a few months' time to see if the inclusion of GeoVista's dependency stack within Iris' lockfile has caused any more headaches than we used to have. E.g. trouble resolving, other packages blocked from advancing
Options if we get dependency problems
- Back out the feature
- Create a plugin package specifically for the bridge Experiences with iris-grib, cf-units, nc-time-axis, mo_pack show that plugin packages are vulnerable to losing resource, so this action would need to come with a plan for altered team culture.
- Copy the
skip_gdal()testing convenience to disable GeoVista-dependent tests and allow GeoVista to not be in dependencies. Developers very rarely run the GDAL-dependent tests, so this action would need to come with a plan for altered team culture. - Extend the optional-core distinction to the tests and to developer environments
- Don't include optional dependencies in the standard testing / developer environment
- Create dedicated CI runs for optional dependencies, which contain fewer tests / run on fewer Python versions. Should keep CI at acceptable speeds.
- Pattern could also be extended to GDAL-dependent tests
... this action would need to come with a plan for altered team culture.
Just a quick note that a planned change in culture was used to justify having fewer mechanical fail safes in the RBMK nuclear reactor design. The culture change never happened, but the reactors went ahead anyway, and Chernobyl happened as a result.
