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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generating the dual mesh #59

Open
Chilipp opened this issue Dec 3, 2020 · 7 comments
Open

generating the dual mesh #59

Chilipp opened this issue Dec 3, 2020 · 7 comments

Comments

@Chilipp
Copy link
Contributor

Chilipp commented Dec 3, 2020

hey @ChrisBarker-NOAA and @jay-hennen (and anyone else who's interested)!

I am currently discussing with one of my colleagues how to best visualize variables that are defined on the nodes and edges of a mesh (see psyplot/psy-maps#32). I already have a visualization for the faces (see https://psyplot.github.io/examples/maps/example_ugrid.html for instance), but nodes and edges are not yet implemented.

We think the best way would be to visualize these variables on the dual mesh.

For a face_node_connectivity like this

image

this looks like the following magenta lines for variables on the nodes
image

and the following magenta lines for variables on the the edges.
image

Currently we know of no library to compute this mesh. The ESMpy library defines a convert_to_dual parameter, but this is only implemented for SCRIP.

I'd be happy to implement this and could think of a method for the UGrid class with something like

    def build_dual_mesh(self, location: Union[Literal["node"], Literal["edge"]]) -> UGrid:

Would this be an interesting enhancement for gridded?

I do not have a clear plan of the algorithm yet, but I'd probably implement it in cython, because it would require quite a lot of lookups and looping. I'd be happy to come up with a PR if this is of interest for you as the developers of gridded.

ping @platipodium

@jay-hennen
Copy link
Contributor

What sort of visualization are you looking for? Similar to the heatmaps in the psplot ugrid example you linked?

Also are we working exclusively with triangle grids here? In all cases this makes grid handling and visualization easier, which is why I bring it up.

In my opinion the best way to visualize polygon data on the vertices is simple Gouraud shading (linear interpolation) as seen in this basic example from matplotlib. This assumes of course that smoothing out the value inconsistency between nodes is what you want. The converse (maintaining the discontinuities) is very challenging indeed, and would probably warrant the enhancement you're suggesting here.

I never quite understood how edge data would get visualized in the triangle case. It sort of makes sense to me in the staggered quad grid case, when you can basically interpolate across the two opposing sides of a quad to get something coherent. What are you trying to visualize here?

@Chilipp
Copy link
Contributor Author

Chilipp commented Dec 3, 2020

thanks for the quick response @jay-hennen!

Also are we working exclusively with triangle grids here? In all cases this makes grid handling and visualization easier, which is why I bring it up.

nope, it's important that the algorithm works for 2D flexible mesh topologies, too. This is also what the proposed function build_dual_mesh function would return. For the dual mesh of the edges, for instance, you'd have triangles at the domain boundary and quadrilaterals in between (see the image above).

In my opinion the best way to visualize polygon data on the vertices is simple Gouraud shading (linear interpolation) as seen in this basic example from matplotlib.

well, I tend to disagree here. For model development, it is often useful to see the exact value in a specific grid cell, without any interpolation.

What are you trying to visualize here?

I must admit that I am also quite new to this thematic (which is why it is not yet implemented in my visualization framework). Nonetheless, a classic example I guess would be a flow from one grid cell into another. left to right would be positive, right to left would be negative. There are of course many different ways to visualize this (e.g. via a quiver plot), but the most generic one without any manipulation on the data or the need for adjustments (e.g. arrowsize) would be the visualization on a mesh as in the last figure above.

@jay-hennen
Copy link
Contributor

Nonetheless, a classic example I guess would be a flow from one grid cell into another. left to right would be positive, right to left would be negative.

Oh I see the quads in the edges case now, but I don't know what visualization you would use with those quads that makes any sense for visualizing flow. What's left-to-right and right-to-left look like in an unstructured grid? I have a feeling it's pretty model-dependent how this gets represented too.

For model development, it is often useful to see the exact value in a specific grid cell, without any interpolation.

Hold on. This makes sense when talking about face data, but how does it make sense when talking about vertex data? If I wanted a visualization of node data to help with actual model development (not a presentation, grant proposal, etc) (and the 'in-betweens' values didn't matter), I would probably just draw the grid, and then put dots with labels on the vertices and edges with their values, and maybe toss in some color/size scaling. It's ugly, but much more informative.

Sorry man. While I can see definite computational use cases for this sort of 'dual mesh' representation, I'm still struggling to see how it helps visualize anything. Perhaps our use case is too simplistic and it's blocking my thinking. We often use gridded to represent an actual physical quantity (say, water Temperature) at specific times at specific locations in X/Y/Z space. In these sort of cases the visualizations are usually fairly obvious.

@Chilipp
Copy link
Contributor Author

Chilipp commented Dec 3, 2020

While I can see definite computational use cases for this sort of 'dual mesh' representation, I'm still struggling to see how it helps visualize anything.

ha, that's fine 😅 the purpose of this issue is not to talk about visualization. That's just my personal motivation for the moment and that would also happen outside of the gridded framework. My question is just, whether you would be interested if I implement the dual mesh generation as a PR to the gridded project, or whether I should rather make my own thing (which I'd prefer not to do).

@jay-hennen
Copy link
Contributor

My question is just, whether you would be interested if I implement the dual mesh generation as a PR to the gridded project,

Oh well, I don't see why not. Go for it.

@ChrisBarker-NOAA
Copy link
Contributor

I am also somewhat confused about what the point of this "dual mesh" is. Is the idea that you want to fill in a complete cell with one color corresponding to the value at a given node?

Nonetheless: the dual of a triangular mesh is the Voronoi Polygons (well, if the triangles are Delaunay -- and if not, you would still build it the same way).

That is -- a node of a triangular mesh can be shared by any number of triangles -- so it's "dual" cell is an polygon, not necessarily a triangle -- and in fact very rarely a triangle -- in your example, you got quads, but they will often be more than four sided.

Voronoi Polygons are build into at least some of the triangularization codes -- but if you want to implement it in gridded -- sure! It's pretty straightforward, if a bit computationally expensive.

I'm also confused about what the purpose of a "dual" to the edges is, as data "on the edge" usually represent fluxes. But I think is is well defined -- so go for that too :-)

@Chilipp
Copy link
Contributor Author

Chilipp commented Dec 4, 2020

thanks for the feedback @jay-hennen and @ChrisBarker-NOAA! I'll come back to this within the next week probably.

It's pretty straightforward, if a bit computationally expensive.

true, the basic theory is quite straight-forward. I think there are three challenges:

  1. the computational efficiency
  2. the domain boundary (for the nodes, for instance, you need to take midpoint of the edge if the edge does belong to one triangle only)
  3. the ordering to make sure the nodes of the dual are in a counterclockwise order.

but let's see when I am getting a bit more concrete next week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants