
[Sponsors] 
February 13, 2007, 17:04 
polyhedral cells

#1 
Guest
Posts: n/a

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 hexbased mesh. I'm assuming that the actual finitevolume 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.


February 13, 2007, 18:14 
Re: polyhedral cells

#2 
Guest
Posts: n/a

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 gatherscatter vertexbased scheme. 

February 13, 2007, 18:26 
Re: polyhedral cells

#3 
Guest
Posts: n/a

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 offdiagonal. 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 nonorthogonality 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 

February 13, 2007, 21:07 
Re: polyhedral cells

#4 
Guest
Posts: n/a

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.


February 14, 2007, 03:20 
Re: polyhedral cells

#5 
Guest
Posts: n/a

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


February 14, 2007, 03:49 
Re: polyhedral cells

#6 
Guest
Posts: n/a

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) 

February 14, 2007, 03:57 
Re: polyhedral cells

#7 
Guest
Posts: n/a

>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) 

February 14, 2007, 03:58 
Re: polyhedral cells

#8 
Guest
Posts: n/a

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 offdiagonal 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 19% less acurate and tet is over 20% worse. However, the numbers are really meaningless: meshtoflow alignment makes the "best" hex mesh an order of magnitude better, which totally knocks out the numbers. There's a Catch22 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 

February 14, 2007, 16:12 
Re: polyhedral cells

#9 
Guest
Posts: n/a

I think thy are call archimedian polyhedrals


February 15, 2007, 13:00 
Re: polyhedral cells

#10 
Guest
Posts: n/a

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 8octants. Nice idea but then someone who works really hard at producing a yplus in a meshing package....they do not get the yplus 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 

March 11, 2014, 07:52 

#11  
Senior Member
Join Date: Jan 2013
Posts: 342
Rep Power: 7 
Dear Dr. Jasak,
About the threedimensional polyhedral cells, it was mentioned that: Code:
polyhedral mesh generators tend to minimise mesh nonorthogonality and face skewness, which is a major source of discretisation error in the FVM. 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 Quote:


Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Import netgen mesh to OpenFOAM  hsieh  Open Source Meshers: Gmsh, Netgen, CGNS, ...  32  September 13, 2011 05:50 
snappyHexMesh won't work  zeros everywhere!  sc298  OpenFOAM Native Meshers: snappyHexMesh and Others  2  March 27, 2011 21:11 
snappyHexMesh aborting  Tobi  OpenFOAM Native Meshers: snappyHexMesh and Others  0  November 10, 2010 04:23 
external flow with snappyHexMesh  chelvistero  OpenFOAM  11  January 15, 2010 20:43 
physical boundary error!!  kris  CDadapco  2  August 3, 2005 00:32 