You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The different flavors of the ICON model use a icosahedral-triangular Arakawa C grid which has most variables located in the center of each triangular cell. See here for an example visualization of a coarse global ICON grid.
As of my knowledge most of the people in the atmospheric modeling community rely on interpolation of the unstructured triangle-centered grid to a regular rectilinear lat-lon grid and do not plot the original triangular data.
Problem Description:
The current functions tricontour/tricontourf require Z to be located on the triangle vertices (x,y) and don't allow triangle-centered data: tricontour(x, y, Z, levels, triangles=triangles, mask=mask) tricontourf(x, y, Z, levels, triangles=triangles, mask=mask)
with x,y: (nvertices,) Z: (nvertices,) triangles: (ntri,3) mask: (ntri,)
Now analog to the implemented tripcolor functionality (see #811) allowing triangle-centered data means one of the following to be accepted: x,y: (nvertices,) Z: (ntri,) triangles: (ntri,3) mask: (ntri,)
or alternatively taking the triangle center locations and optionally maybe neighbor triangle indices for faster computation: x,y: (ntri,) Z: (ntri,) mask: (ntri,) [neighbors: (ntri,3,)]
One currently possible workaround (but not for masked data) is by letting matplotlib compute the delaunay triangulation of the polygon dual grid which means taking the triangle-centered data coordinates as new vertices of the dual grid. Therefore the following usage is a current workaround: x,y: (ntri,) Z: (ntri,) triangles: (ntridelaunay,3) mask: (ntridelaunay,)
where for large grids of regular triangles: ntridelaunay ≈ 2 * ntri
Masking triangle-centered data is not possible this way because the mask from the data comes in shape (ntri,) and not in the accepted (ntridelaunay,) and alternatively np.nan values are not allowed in Z.
Example plot of tricontourf used with this workaround way with fake data values located on the centers of the yellow triangular grid (=vertices of the black hexagonal dual grid which the delaunay triangulation divides into 4 triangles per hexagon):
Proposed solution
I understood from here how the linear interpolation algorithm along the edges (black in the figure) works but as I don't understand how the currently implemented masking works I can't propose a solution to this, @ianthomas23 maybe you can explain it to us and say something about possibilities. The idea is, not to just exclude the masked data points before delaunay triangulation but to have the contour lines end at the boundaries to the masked triangles (yellow in the figure).
The text was updated successfully, but these errors were encountered:
Masking just removes the masked triangles from the triangulation, so if you have a Triangulation and set the mask it is functionally equivalent to creating a new Triangulation from the first one but with the masked triangles completely removed. It is just a convenience function for those who want a Delaunay triangulation but, for example, don't want the complete convex hull to be triangulated.
Contouring is intrinsically grid-based functionality rather than cell-based. So if you want to contour a polygon (we only normally deal with triangles and quadrilaterals) you need values at each of the grid points, i.e. vertices of the polygon. If you have cell-based data you either need to use a cell-based rendering algorithm (e.g. pcolor), or you have the option that you are considering which is to create a new mesh having vertices where your data is located.
You have considered one approach of Delaunay triangulating your dual grid, but assuming your grid is finite (i.e. not the whole Earth) you need to deal with the edges of the domain. So presumably your dual triangulation will include not only the centre of each of the original grid triangles but also all of the vertices of the original grid that lie on the one or more boundaries of your grid.
The alternative, which will be easier to code and probably easier to understand is to split each of your original grid triangles into 3 new triangles by adding new grid points at the centres of the triangles.
Either approach needs values of the field that you wish to contour defined on all the grid points, so certainly for all grid points on the boundaries of the domain, and in my second example for every original grid point. So you need some approach to interpolate the values at these grid points. You could use a geometric approach and do some sort of weighted average of the values of the triangles that are incident towards each vertex, but probably you really need to use an approach that is consistent with the differential equations that form your mathematical model.
You could argue that there should be a handy function that takes one triangulation and returns a second one that includes points at the centres of each of the non-masked triangles of the first triangulation. There could be an option for which of the 2 approaches to use for this. But it couldn't assign values at these new points based on values in the centres of the first triangulation's triangles as they need to be physically realistic according to the numerical model. The end user will always have to specify these values. Given that the returned triangulation contains more points that the first triangulation, how would you even pass enough information back to the user so that they can identify which new grid point is which?
Problem
Relevance:
The different flavors of the ICON model use a icosahedral-triangular Arakawa C grid which has most variables located in the center of each triangular cell. See here for an example visualization of a coarse global ICON grid.
As of my knowledge most of the people in the atmospheric modeling community rely on interpolation of the unstructured triangle-centered grid to a regular rectilinear lat-lon grid and do not plot the original triangular data.
Problem Description:
The current functions tricontour/tricontourf require Z to be located on the triangle vertices (x,y) and don't allow triangle-centered data:
tricontour(x, y, Z, levels, triangles=triangles, mask=mask)
tricontourf(x, y, Z, levels, triangles=triangles, mask=mask)
with x,y: (nvertices,) Z: (nvertices,) triangles: (ntri,3) mask: (ntri,)
Now analog to the implemented tripcolor functionality (see #811) allowing triangle-centered data means one of the following to be accepted:
x,y: (nvertices,) Z: (ntri,) triangles: (ntri,3) mask: (ntri,)
or alternatively taking the triangle center locations and optionally maybe neighbor triangle indices for faster computation:
x,y: (ntri,) Z: (ntri,) mask: (ntri,) [neighbors: (ntri,3,)]
One currently possible workaround (but not for masked data) is by letting matplotlib compute the delaunay triangulation of the polygon dual grid which means taking the triangle-centered data coordinates as new vertices of the dual grid. Therefore the following usage is a current workaround:
x,y: (ntri,) Z: (ntri,) triangles: (ntridelaunay,3) mask: (ntridelaunay,)
where for large grids of regular triangles: ntridelaunay ≈ 2 * ntri
Masking triangle-centered data is not possible this way because the mask from the data comes in shape (ntri,) and not in the accepted (ntridelaunay,) and alternatively np.nan values are not allowed in Z.
Example plot of tricontourf used with this workaround way with fake data values located on the centers of the yellow triangular grid (=vertices of the black hexagonal dual grid which the delaunay triangulation divides into 4 triangles per hexagon):

Proposed solution
I understood from here how the linear interpolation algorithm along the edges (black in the figure) works but as I don't understand how the currently implemented masking works I can't propose a solution to this, @ianthomas23 maybe you can explain it to us and say something about possibilities. The idea is, not to just exclude the masked data points before delaunay triangulation but to have the contour lines end at the boundaries to the masked triangles (yellow in the figure).
The text was updated successfully, but these errors were encountered: