Support unstructured plotting

[bjlittle]

🚀 Pull Request

Description

This PR introduces pyvista plotting support of unstructured UGRID meshes.

This is an initial foray into visualisation of unstructured meshes to garner feedback. I suspect it will strongly seed the conversation and direction that we may or may not take, but it certainly showcases the potential of what could possibly come.

That said, it is highly experimental code, so I've not invested any time in testing, other than to confirm visually and functionally that it's doing what I intended. And that's okay by me (for now).

This PR also includes the extra dependencies to support pyvista, but I've also included the colorcet and the gorgeous cmocean perceptually uniform colormaps.

Why use more words, when I can let the plotting do the talking...

C48 SST Mollweide

C48 SST Mollweide with Threshold >295K

C48 SST Spherical

C48 SST Spherical with NaN Threshold

C48 SST Spherical Interactive

---

Consult Iris pull request check list

[bjlittle]

Interesting... cirrus-ci containers don't have opengl installed 🤔

[trexfeathers]

Interesting... cirrus-ci containers don't have opengl installed 🤔

Is that interesting? In my experience CI containers have the absolute minimum installed. It's caused me no end of problems in the past.

It is easy enough to have Nox install such a thing?

[bjlittle]

@trexfeathers We may simply need to use our own custom container on CI with the appropriate system dependencies installed. That should be relatively straight forward. Or there may be something what we can use out-the-box... just needs a little bit of research - and I'm on that 😉

This is not something to be configured at the nox level, which validly assumes a minimum install of platform specific libraries that conda (and its environment packages) must ultimately rely on.

I just need to explore some options. This was always going to come up sooner or later, hence why I was keen to push this to understand any early issues.

[bjlittle]

@trexfeathers

Ohhh this looks like just the very thing we need https://cirrus-ci.org/guide/docker-builder-vm/#dockerfile-as-a-ci-environment 😍 🥳 🚀

[trexfeathers]

Correct me if I'm wrong:

• At the moment: anyone can run a test suite identical to our CI on their local machine (so long as they have Nox installed).
• After this PR: only people with OpenGL (and Nox) can run a test suite identical to our CI, even though we haven't yet added any new tests.

[bjlittle]

@trexfeathers Clearly, yes.

It's a dependency requirement. That's why ultimately we don't want pyvista as a core dependency of iris. For me, it's an optional dependency that you pull-in if and when you want unstructured support... and not all people will want unstructured support. But if they do, then they need opengl as a platform dependency, and that's on them to ensure rather than us.

This is exactly the same for any similar package, such as napari or vispy et al.

We still need to separate concerns here, to make pyvista an truly optional opt-in dependency - but that work will follow. It's okay (to me) to hardwire this in the feature branch just to enable plotting capability. However, I would be hesitant merging the feature branch as is to master, given this additional platform specific dependency on opengl. It would certainly require careful consideration, but at this early moment in time I personally would err on the side of caution.

[pp-mo]

Just a few initial tiny comments FYI.
I haven't really got to the core of this yet...
Loving it so far though 😁

[jamesp]

In the C48 SST Spherical with NaN Threshold example above, am I seeing Australia on the back side of the sphere showing through Africa?

[bjlittle]

@jamesp i've thresholded the NaN out, just for effect... the user can control whether this happens or not... but yeah, you can see through the holes to the antipode mesh underside.

Trippy, huh?

[bjlittle]

@trexfeathers I don't want to use anything from iris within the plotting at the moment to keep these concerns separated i.e., the plotting is going to be migrated to its own repo and I don't want circular import dependencies.

Also, the treatment of wrapping is all going to change as a first step after this PR, as we need a more robust treatment of tearing and re-joining the connectivity for any lon_0 of a planar projection.

So at this point, this doesn't have to be bullet proof... well, that's what I was aiming for.

I'll add a comment to the code that reflects this better 👍

[bjlittle]

Ping @jamesp

I've also now got smoother slider rendering of the scene, and the cell picking is connected to the slider and auto-updates... so essentially you can do a quick-viz interactive zonal min/max/mean of anywhere.

Also, now you can cell pick over NaNs, which wasn't working before.

Note that the nCells count includes NaN and non-NaN cells, but only non-NaN cells contribute to any statistic. Don't know if it's worth while highlighting the number of NaN cells selected... which is easy to do.

(This point of all of this is to garner feedback from users - it's all customisable, and pretty much anything-ish is possible - but I just want something that is ball-park useful)

[bjlittle]

Same again, but for the +mollweider projection

[bjlittle]

BTW I also have texture mapping up my sleeve... and it's looking really, really good.

This will allow you to wrap (texture map) any raster image over the mesh geometry... be that a hi-res image of the Earth or a picture of your favourite pet 😉 ... then you can plot cube mesh data over the texture map to complete a really rich visualisation. So imagine the above two plots, but with the grey masked NaN land regions replaced with something like https://github.com/pyvista/pyvista/blob/master/pyvista/examples/2k_earth_daymap.jpg.

The reason why it's not included here is that after a bit of research I discovered that you need to create an overlapping seam in the connectivity, otherwise you end up with texture mapping smearing across meridian cells due to texture mapping interpolation.

Now I know what to do, I just need to do it... at that point we can make texture mapping available as an initial plotting feature.

[trexfeathers]

Can confirm all of @pp-mo's comments are now addressed. I'm currently attempting a full review of everything that's here. It's all a bit new to me so may take a few hours.

[bjlittle]

@trexfeathers Here's an early bird example of texture mapping, but with interpolation smearing. Note that there is unwanted color blending of the data with the texture map within a cell, but this is easily remedied.

I've also used a kdtree to fast find the 180th meridian cells and drawn a path (white liine) from the north pole round to the south pole on the 180th meridian. Note the texture map smearing in the immediate eastern cell, due to interpolation.

The approaches to fix this are to either not have a fully connected mesh i.e., a minuscule tear (:-1:), or have an overlapping mesh with a seam i.e., duplicate cell node points at the 180th meridian (:+1:).

[trexfeathers]

@bjlittle just shout when you're done with the CI experiments and I will merge.

[bjlittle]

@bjlittle just shout when you're done with the CI experiments and I will merge.

@trexfeathers I'm going to take you at your word, and you have also explicitly approved this PR 👍