-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
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? |
thanks for the quick response @jay-hennen!
nope, it's important that the algorithm works for 2D flexible mesh topologies, too. This is also what the proposed function
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.
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. |
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.
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. |
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). |
Oh well, I don't see why not. Go for it. |
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 :-) |
thanks for the feedback @jay-hennen and @ChrisBarker-NOAA! I'll come back to this within the next week probably.
true, the basic theory is quite straight-forward. I think there are three challenges:
but let's see when I am getting a bit more concrete next week |
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 thisthis looks like the following magenta lines for variables on the nodes
and the following magenta lines for variables on the the edges.
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 likeWould 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
The text was updated successfully, but these errors were encountered: