I keep reading numerous references to polyhedral mesh which may be employed in both Star and Fluent as being more accurate per cell count than either tet or hex-based mesh. I'm assuming that the actual finite-volume discretisation is almost identical to that used for tets/hex just generalised at the data structure level to allow for arbitrary shaped volumes? Yet neither reference appears to mention any fact of any computational overhead when using polyhedral cells. Surely polyhedral cells having 3/4 times or greater number of faces than tetrahedral or hex cell mesh impose significant overhead? Could anyone commment on the actual discritisation or computational overhead incurred with polyhedral mesh or is this fact glossed over.

Hello, polyhedral cell have been "stolen" from open source maths, image filtration and medical (morphology detection) programs that were discretizing doamins for visualization (www.siam.org, www.inria.org). It is not really clear if it is usefull for CFD.

The mathematicians said the best technique is to limit the type of polyhedral one must use: dodecahedron, octahedron,...i.e. only use the standard shape with chose defined geometrical properties and quality.

If bizarre polyhedral are used (irregular, concaves, etc...) there is few chance to be able to solve a system of equation. Holomorphic functions won't be holomorphic, linear gradients won't be conserved, etc...

Using polyhedrals isactaully equivalent in term of memory to a gather-scatter vertex-based scheme.

Well, I have been doing polyhedral cells from mid 1990s and at that time the biggest problem was how to create them. Today there's a few decent algorithms for automatic polyhedral mesh generation and hence the hype.

Returning to the actual question, polyhedra are very useful for the Finite Volume Method. In fact, FVM tidily generalises into loops over faces and cells and the cell shape is irrelevant (the trick was to do the same in mesh analysis). The rest (volume integration, surface interpolation, convection schemes, matrix structure and properties etc.) are all the same as on other meshes.

Regarding the tet, hex and polyhedral mesh with the IDENTICAL NUMBER OF CELLS, a poly mesh is much richer in the off-diagonal. This means extra storage in the sparse matrix format, but it turns out that such matrices are actually easier to solve. If you cook in the "equivalent accuracy" of various mesh types into the story (measuring this gets tricky, I remember writing a paper on it a while back), it turns out that a polyhedral mesh will have a marginally lower cell count.

Furthermore, polyhedral mesh generators tend to minimise mesh non-orthogonality and face skewness, which is a major source of discretisation error in the FVM. When you put all this together, it turns out that a poly mesh simulations run faster, use approximately the same storage for equivalent accuracy and are easier to converge. Lots of caveats required, but this is the base of the story.

Hrv

I agree with almost everything Hrvoje says. Its true that there is more overhead involved in a single polyhedra than a single tet, but you need so many fewer to get the same accuracy that you more than make up for the extra overhead in faster solution times with less total memory. The only additional caveat is that cell shapes still matter. You can't have cells that are so twisted that faces pass through each other for example. Highly concave cells are still not usually solvable.

Thanks Hrvoje, do you have any numbers for "marginally lower cell counts" for equivalent accuracy, are we talking 10,20,40%? Or is it case-by-case?

adding to previous comment:

look also at literature related to meshless methods, some of them especially which that are based finite element (FEM not FVM!) make polyhedral mesh (or virtually make it) then solve pde on it.

e.g. seris of work due to Onate (meshless FEM)

>The mathematicians said the best technique is to limit the type of polyhedral one must use: dodecahedron, >octahedron,...i.e. only use the standard shape with chose defined geometrical properties and quality

interesting, these types are, subset of basic primitives units in crystaline structures (especially close packed ones), in fact mesh that nature is used, could you please give more details about such mathematical veiwpoint (cite suitable reference)

The numbers are so easy to "cook" that I would not dare rely on them. Also, objective measures are difficult to define because of different characteristics of matrices coming out of polyhedral meshes that actually make them easier to solve. For example, counting mesh faces counts off-diagonal entries in the matrix but having fewer rows (cells) with the same number of faces makes the matrix better "connected" and easier to solve.

You can measure the accuracy in terms of the same number of cells (per unit volume), same number of matrix rows, same number of matrix coefficients, a linear measure of cell size (edge length) and a bunch of others. For isotropic problems with no defined mesh orientation and defined flow direction you can show that ON AVERAGE hex is best, poly is about 1-9% less acurate and tet is over 20% worse.

However, the numbers are really meaningless: mesh-to-flow alignment makes the "best" hex mesh an order of magnitude better, which totally knocks out the numbers. There's a Catch-22 in play: if you know the flow field, you can build the mesh to align with the flow and considerably reduce the error. Of course, if you know the solution, you needn't bother with the simulation in the first place

In places where we know the flow, e.g. near walls, building stretched boundary layer meshes will give you greatest improvement. What I CAN say without caveats is that polyhedral cells are a better way of filling volume meshes than tets, in cell count, mesh quality and matrix characteristics. Just look at those beautiful convergence curves for turbulent flow in complex geometry when comparing tet and poly meshes.

Hrv

I think thy are call archimedian polyhedrals

Hi Hrv,

an interesting point you raise about the issues the user has to do to "get to" the finite volume mesh that the flow is eventually solved on.

One of the drawbacks of polyhedral meshes is that the user is often used to meshing something up and can see (and be satisfied with) the level of discretiation in the meshing process. BUT then the actual discretization is changed in the solver....the numerics may be better...but it is not what they thought they had for discretiation.

There is a commercial code out there (you may be familair with it ;-) ) That one creates polyhedra also for hex meshes out of 8-octants. Nice idea but then someone who works really hard at producing a y-plus in a meshing package....they do not get the y-plus they expect. Maybe the numerics work out better but it just is not what they expect from meshing!

Subtle issues like this often mean that a user or company is reluctant to give up on their old practices and validations...sometimes for good reasons sometimes for bad.

It would be nice to see meshing packages that anticipate the poly construction...so we can change things at that level. Do any meshers do that yet??

This is a nice discussion btw.

Regards,

Bak_Flow

[openfoammaofnepo]

Dear Dr. Jasak,

About the three-dimensional polyhedral cells, it was mentioned that:

polyhedral mesh generators tend to minimise mesh non-orthogonality and face skewness, which is a major source of discretisation error in the FVM.

In the polyhedron you studied, does each line between the centriods of cell P and cell N pass through the each face in the polyhedron? In my case, I also have the set of polyhedron mesh (each cell may have different amount of faces) and the discretization of the convection term using FVM does not give me the correct results.

Besides, do you have comments about way to examine the quality of the polyhedron mesh in terms of the minimizing the discretization errors?

Thank you so much.

OFFO

Originally Posted by Hrvoje Jasak
;47883

Well, I have been doing polyhedral cells from mid 1990s and at that time the biggest problem was how to create them. Today there's a few decent algorithms for automatic polyhedral mesh generation and hence the hype.

Returning to the actual question, polyhedra are very useful for the Finite Volume Method. In fact, FVM tidily generalises into loops over faces and cells and the cell shape is irrelevant (the trick was to do the same in mesh analysis). The rest (volume integration, surface interpolation, convection schemes, matrix structure and properties etc.) are all the same as on other meshes.

Regarding the tet, hex and polyhedral mesh with the IDENTICAL NUMBER OF CELLS, a poly mesh is much richer in the off-diagonal. This means extra storage in the sparse matrix format, but it turns out that such matrices are actually easier to solve. If you cook in the "equivalent accuracy" of various mesh types into the story (measuring this gets tricky, I remember writing a paper on it a while back), it turns out that a polyhedral mesh will have a marginally lower cell count.

Furthermore, polyhedral mesh generators tend to minimise mesh non-orthogonality and face skewness, which is a major source of discretisation error in the FVM. When you put all this together, it turns out that a poly mesh simulations run faster, use approximately the same storage for equivalent accuracy and are easier to converge. Lots of caveats required, but this is the base of the story.

Hrv