Structure For Shearing Curvilinear Mesh

Development
1

Hi!

I have written a C++ plugin to read data from a grid-based Hydro code (called Disco: https://arxiv.org/abs/1605.03577). The code utilizes a moving mesh where grid cells can move on “tracks” and shear past each other and outputs in a custom HDF5 format.

Disco’s grid is written in Cartesian, cylindrical, or spherical coordinates. In Cartesian mode, the cell “tracks” are fixed to a rectilinear grid in X-Z, while the cells independently move in Y. In cylindrical or spherical mode, the tracks are in a logically cartesian grid in R-Z or R-Theta, while the cells move freely in Phi. Each Disco cell is a coordinate box, for instance: (R1,R2)x(Theta1,Theta2)x(Phi1,Phi2).

I have a basic serial version of the reader running using an UnstructuredGrid, where each Disco cell is split into several hexahedral VTK cells. Currently the splitting is not necessarily consistent between adjacent tracks, resulting in a not-quite water tight mesh (some cells slightly overlap, others may have small voids between them). Perhaps as a result of this, when I try to plot stream lines many terminate prematurely within the domain.

I was worried that splitting each disco cell into several VTK cells would cause memory issues, especially since the cell data for each disco cell would be copied into several VTK cells, so I also wrote a not-quite-watertight polyhedral setup. This, however, ended up being significantly slower than the hexahedral mesh.

My questions for the community:

  1. What can cause stream-lines to terminate prematurely? Does the stream line filter require a water-tight mesh?
  2. Is a water-tight mesh critical for most filters?
  3. What are the performance/memory trade-offs between a mesh of hexahedral cells vs polyhedra? Does one tend to perform better?
  4. Are there general guidelines for constructing efficient Polyhedral meshes?

Any help would be greatly appreciated!

2

  1. The most common reason for a streamline to terminate early is for it to leave the mesh (or the filter thinks it left the mesh). If the streamline happens to hit a void, then it is going to terminate. Unfortunately, it is also possible for the cell locator to get confused around a not-connected part of the mesh. You might try swapping out the cell locator used in the streamline. I don’t think there is a way to do that through ParaView scripting, but it should be possible inside a custom filter.

  2. Whether a water-tight mesh is critical depends on the output you expect. For example, let’s say you are running the Gradient of Unstructured DataSet filter. The filter estimates the gradient at all points in your mesh. At points along this non-watertight seam in the mesh, you will get a discontinuous gradient on the opposite sides of the non-watertight part. Is that wrong? If you consider this non-watertight area just a mesh artifact of an otherwise continuous domain, then the result is wrong. However, if you consider this a genuine discontinuity in the volume, then the result is probably right.

  3. Because polyhedra cells are so general, operations on them require quite a bit more computations than cell types of known structure. The operations that streamlines have to do (find a cell containing a point, interpolate field values to an interior point) will be particularly expensive in polyhedra. Representing a polyhedra as a group of hexahedra will probably always be faster.

3

Thanks so much! This helps a lot.

The non-watertight sections are mesh artifacts. Guess I should invest the effort in building the mesh better :stuck_out_tongue:

So Hexahedra tend to be more efficient than Polyhedra (at things like stream lines at least). To build a watertight mesh, I’ll probably have to explicitly make a mesh of Tetrahedra. Do you have any insight whether this would be more or less efficient than something like ConvexPointSet? This probably suffers similar triangulation issues to Polyhedra, but would be less objects than Tetrahedra…

Alternately, is there a filter that adjusts a mesh to fix small overlaps/voids? My first implementation of the reader used a MultiBlock dataset of StructuredGrids, one per track. This was much faster, but since the tracks didn’t know about each other the overlaps/voids were too significant, could easily be seen by eye. A filter that would take in this and build a watertight mesh would be perfect, but this is probably too niche a task for a general filter.

Thanks again!