Closed tcaduser closed 6 years ago
No, Omega_h doesn't use Delaunay refinement at all. Likewise, Gmsh uses the same operators as Omega_h to post-process the initial Delaunay mesh to remove low-quality elements. For a wide range of applications, I believe it is better to have high quality elements by measures that take volume into account (Delaunay meshes often have near-zero-volume tetrahedra). It should be straightforward to design a finite volume code that doesn't require Delaunay input to calculate surface areas. Dual volumes can be defined in terms of tetrahedron centroids instead of Voronoi cells, in case that is the root of the issue.
This is an existing finite volume code. Near zero volume are not a problem. The volumes can vary by several orders of magnitude, depending on what is happening around different locations in the mesh. The Delaunay mesh is crucial for node-centered finite-volume TCAD simulators. Are you aware of any existing open source meshing tools that can create a Delaunay tetrahedral mesh?
I think Gmsh begins with a Delaunay method, so it may be sufficient just to disable "optimization" in Gmsh (the non-Delaunay post-processing step). There is also TetGen, which is pure Delaunay but takes only a triangle surface mesh as input, and NetGen, which supposedly can accept CAD-like input, although I have no experience with NetGen.
I think I've answered this question so I'll close it. Please comment if there is more to answer.
Are the meshes from your tool guaranteed to generate Delaunay tetrahedra? Unfortunately the 3D meshes I have gotten from gmsh are not Delaunay. My finite volume simulator is getting bad results since it relies on this in order to get the proper surfaces area when calculating flow.