CFD Online Discussion Forums

CFD Online Discussion Forums (
-   Main CFD Forum (
-   -   Tetrahedral vs. Hexahedral Meshing for CFD (

Andy Bartels August 17, 2000 11:10

Tetrahedral vs. Hexahedral Meshing for CFD
Why are hexahedral meshes preferred over tetrahedral meshes for CFD? I have read, Tetrahedral meshes are not ideal for flows involving shear layers and lead to problems with numerical diffusion. Thank you in advance.

John C. Chien August 17, 2000 11:50

Re: Tetrahedral vs. Hexahedral Meshing for CFD
(1). The definition of the boundary layer (wall boundary layer or free shear layer) says that the streamwise change is much smaller than the cross-stream change. Therefore, the streamwise second-order diffusion terms can be neglected. (2). The other way to say is that the streamwise change is very slow (gradual). Thus, one do not need to use very fine mesh size in the streamwise direction. As a result, you get the thin brick type mesh, which is called hex mesh. (3). If you replace the mesh by the tet mesh,keeping the size of the mesh (total number of grid points or cells) about the same (or same order of magnitude), then you will get highly skewed tet mesh, which is not good for numerical accuracy. (thin knife edge cells) In this case, tet mesh is not acceptable. (4). But, if you use the short edge of the brick cell to create many more tet cells, then you will have good tet mesh again. But then the total number of tet cells will be many more times that of the hex cells. So, the cost will be many times higher. This is not needed because the resulting fine mesh in the streamwise direction does not improve the solution accuracy.

Lars Liavåg August 18, 2000 01:52

Re: Tetrahedral vs. Hexahedral Meshing for CFD

If I understand you correctly, a high quality tetrahedral mesh with relatively even (or smooth) cell heights along a wall should yield reasonable results. My understanding up to now has been that part of the problem is that cells with just a vertice or an edge (but no face) adjacent to a wall are not treated as wall cells. Thus, the law of the wall is not applied to those cells, and tets that in fact are neighbouring wall cells are therefore subject to different turbulence modeling. I use STAR-CD and ICEM Tetra/Prism and struggle a lot to get well behaved prism layers on my models. Your comments would therefore be much appreciated.


Joern Beilke August 18, 2000 06:56

Re: Tetrahedral vs. Hexahedral Meshing for CFD
The problem with tets and wall functions mainly depends on the implementation in a current code.

If you want to avoid the prism-layer you have to use something which is called "meshless-2layer" (starcd vocabulary), where a separate equation (ode) for the wall treatment is solved for the cells, which touch the wall with at least one vertex.

This seems to be the only practical way to overcome the problems with y+ (30 < y+ < 100) for me.

I think that vectis and floworks are using this approach, but they keep their wall treatment very secret.

In the current starcd implementation you have to use the prism layers for getting "correct" results.

Lars Liavåg August 18, 2000 08:14

Re: Tetrahedral vs. Hexahedral Meshing for CFD

Very interesting indeed. Do you use STAR-CD too? Is this method in any way related to the two-layer or Low-Re turbulence models provided in STAR-CD? These models require a very dense mesh near walls. Does this go for the meshless 2-layer method as well? What do you mean by "starcd vocabulary", by the way? Has the method been implemented in previous versions of STAR-CD?

Lars Ola

Joern Beilke August 18, 2000 09:05

Re: Tetrahedral vs. Hexahedral Meshing for CFD
The method is on the development list for several year now but I don't have any idea about the priority.

The idea behind this is, that you replace the fine mesh near the wall (for 2layer and low-Re) by an analytical solution. That's why it is called "meshless".

About the vocabulary:

The same features sometimes have different names in different codes. For instance "frozen rotor" in TascFlow is called "explizit mfr" in Starcd. So it is always a bit tricky to compare two codes by just reading a feature list.

John C. Chien August 18, 2000 11:10

Re: Tetrahedral vs. Hexahedral Meshing for CFD
(1). If I had the time, I would continue my testing on the unstructured mesh using tet/tri. Currently, I am using structured hex mesh.(2). And I must say that these commercial codes are helping me a lot to understand the problem. So, sometimes, the commercial codes are very good for the professionals to find the problems, not the answers. (if the codes are not available, I would not be able to find out all these problems.) (3). Back to your problem. For the free shear layer , you can get a dense tet/tri mesh region to cover it and blend the mesh into the coaser free stream region. (4). For the wall region, you got another complication about the boundary conditions, or more precisely, the implementation of the boundary conditions. The cell which has only one vertex attached to the wall, simply do not have surface area. So, in this case, the wall cells will be represented by a layer of saw-tooth type arrangement. (5). And if this layer of cells is not uniform, the cell size changes along the wall, then it will affect the wall function results. So, normally, it is a good idea to keep the first few layers as uniform as possible. It also will work for 2-layer model, when you keep the Y+ to one. At that condition, the velocity is linear and the error is also small. (6).For 2-D problem, it is possible. For 3-D problem, you can easily run out of the memory space due to the huge amount of the tet cells on the surface. (7). For hybrid mesh,I have used the early version of the Fluent prism cells (hybrid or boundary layer mesh) to improve the handling of the mesh near the wall. I think it is the right approach, but the early version has many limitations in it. It was also slow (relatively speaking) to claculate numerically these prism layer. You actually grow the prism cells one by one from the wall outward. (8). Based on my experience, it does improve the calculation of the wall layer properties, for example the total pressure loss. (relative to the all tet/tri approach). (9). If the surface is simple, you should have no problem in using this type of hybrid mesh. For complex surface topology, especially around the concave corner, you can run into troubles because of the thickness of the cells. (10). Using the ICEM code(s) requires a lot of patience. I have been using the ICEM/hexa recently. I would say that it is one working approach, but optimization is rather tedious and time consuming,especially for complex geometry. (11). My personal approach is always the analytical approach. It is just too much work to deal with each block, edge, distribution to handle the mesh interactively. (12). So, in reality, I use the global parameters to set the cell distribution all the time, which I know is not going to produce the optimum mesh. (13). In using other mesh generation program to generate mesh for low Re or two layer model, sometimes I had to try 30 to 100 arrangements to get a working mesh.(structured mesh) (14). So, there is a long way to go in this area related to the commercial cfd codes (mesh,solver,boundary conditions). But you can study the commercial cfd codes to get the feeling about the state of the art in cfd.

clifford bradford August 18, 2000 15:30

Re: Tetrahedral vs. Hexahedral Meshing for CFD

is it necessarily true that highly stretched tris/tets will give you numerical errors? I'd assume that the definition of a "poorly shaped cell" varies according to numerical scheme (as well as other things but lets assume all things equal). Are there numerical schemes that are less susceptible to errors due to poorly shaped cells? I have seen papers whose titles seem to imply that but i didn't read them (unfortunately).

Also it was mentioned somewhere in this thread that cells that only touch a boundary with a node will cause problems in the solutions because the BC are not applied to those cells. I have some idea but could you please explain? would it be possible to overcome this to some extent by using higher order elements (using finite element terminology) at the boundaries. I'd suppose a quadratic element would be appropriate. what do you think.

John C. Chien August 18, 2000 16:52

Re: Tetrahedral vs. Hexahedral Meshing for CFD
(1). Well, first of all, I am talking about the commercial codes. It is possible to make improvement as you have suggested. (2). But in the commercial codes, if the skewness exceed the limit, the code will give you warning, or even prevent you from moving a step further. So, the code vendors have already learned that and explicitly placed the warning message there. (3). I think, anything is possible. I have not done extensive research in this area, so, I am not going to say which way is the right way to go. (4). In a thin brick, the coner angle is always 90 degrees. So, you can always find positive area even around the corner. (5). For the highly skewed tet/tri cell, the area just gets smaller and smaller as you approach the far end of the vertex. If the value at the vertex is also very small, then the contribution from that vertex will become very small. And it is not going to create problems. (6). If the value at that vertex is finite, it will become a problem to maintain the accuracy, because you are dealing with a finite value, a small area and trying to get back a finite value.

Srinivasan Arunajatesan August 20, 2000 07:58

Re: Tetrahedral vs. Hexahedral Meshing for CFD

I have some experience with simulating wall bounded and shear layer flows using unstructured codes. BTW, our code is an edge based code, not a cell based code. BUt I will try and extend some of the points to cell based codes too.

Like John pointed out, the wall normal gradient (or cross stream gradient in shear layers) is the dictating factor when generating a mesh at the walls/shear layers. In order to resolve the steep transverse gradient while keeping mesh size low, hexes are the optimal cells to use. This is because they permit the use of high aspect ratio cells (note that this is different from skewed cells for hexes). Hence, the streamwise resolution can be small without sacrificing transverse resolution.

For tet meshes the basic issue is that you have to have near isotropic tets to get good solutions on them. In tets, aspect ratio and skewness are inextricably linked.Now, if you try to generate a tet mesh for such a region, the size of the tet mesh becomes very large because, the size of the tet is dictated by the transverse resolution requirement.

With respect to cell skewness and scheme resolution, the point is that since most solvers solve a 1-D Reimann problem normal to the face, if the mesh element on which this is done ( cell faces in cell centered cells and edges in edge based codes) should be as close as normal to the direction of flow at any given point for best accuracy. With tets in shear/boundary layers, this is not possible. With hexes, you can do this easily. THat is another reason why they are better. Otherwise, you will have to play all kinds of games with limitors to get reasonable solutions in shear layer regions.

Now, with respect to boundary condition implementation, the issue is, like someone pointed out, the cells with one vertex on the wall.

- In an edge based scheme, where the values are stored at the vertex, this doesnt make too much of a difference for the wall functions implementations. However, for the pressure (and adiabatic wall) condition, you will need an edge normal to the wall (to set the normal pressure gradient to zero).

- In cell based schemes wall function implementations are a pain. Pressure (and temperature) conditions are easier on walls with cell based schemes, but even here, the cell centroid has to be normally above the wall face centroid for this condition to work well.

Hence you can see that the only way to get reasonable solutions near walls and in shear layers is to use hexes in these regions. With Tet meshes, you can use prisms in a few layers normal to the wall. Generating these is easy, you can advance the wall surface mesh using standard advancing front type methods to form prism cells. This works really well if you can get enough layers off the walls ( this is a problem for concave surfaces).

Hope this helps, Srinivasan

John C. Chien August 20, 2000 13:57

Re: Tetrahedral vs. Hexahedral Meshing for CFD
(1). Very nice. (2).The fact is the physics of the problem (thus the solution itself) controls the optimum mesh required. (3). While in structure analysis, such non-linear boundary layers normally do not exist. (4). It is a long trip back to the old brick type mesh. I made a comment in early 90's on the tet/tri mesh when giving a lecture at a research institute, saying that it is not the right approach for fluid dynamics problems. (You must have seen a few velocity vector plots for flow over some character shape objects showing off the capability to treat arbitrary geometry using tet/tri mesh. The fact of the matter is that those solutions are wrong. They will have to show that they can resolve the wall layer and the free shear layer for the real world problem. ) (5). So. borrowing the technology from the stress analysis side (mostly linear problems) is not going to work. (luckly, there were not big wars in 90's, so, it is all right for cfd to take a 10 year vacation.) (6). The tet/tri optimum shape is good for diffusion solution (thus good for diffustion equation also). On the other hand, hex/brick shape is good for convection solution. It may sound like that by using both types of mesh in a convection-diffusion problem would solve the problem, but in reality, you are really back to the ancient inviscid/boundary layer coupling approach. The zonal coupling in theory is possible, but in reality, it is too complicated (hard to do matching at unknown surfaces) (7). There is simply no general solutions of the fluid dynamics problems, each problem is unique and requires special attention. Using automatic tet/tri mesh for every problem? It is possible, but it is likely that one will run out of the memory before getting a solution. (8). That is why I said, even though you are not getting good solutions form commercial codes, it is a good way to learn the state of the art of cfd. (The state of the art does not mean that it is in the most advanced state. It simply says that it is the current state.) (9). So, far, to get a good solution, one needs a good mesh consistent with the solution. And the process is tedious and time consuming. It is the solution which determines the type of the optimum mesh required, not the other way around. It is silly to say that we need the solution to determine an optimum mesh, so that one can solve the equations to find the right solution. (may be that is the reason why we are getting the wrong solutions all the time. )

Lars Liavåg August 21, 2000 03:43

Re: Tetrahedral vs. Hexahedral Meshing for CFD

I have read the rest of this string and find it increasingly discouraging for those of us who need to use automatic mesh generators to get (any) results in time. So I guess I'll hang on to the more uplifting comments, i.e. yours...

Thanks for notifying me in the first hand that the meshless 2-layer method exists and is on CD's development list. This way, I can ask questions to (or if you like, put pressure on) CD and perhaps contribute to clarifying its future in STAR-CD.

You state earlier in the string that this method seems to be the only practical way for you to overcome the problems with y+ (30 < y+ < 100). Is it correctly understood that you use this method in your daily work? What are your experiences, and what software are you using if not STAR-CD? Have you heard of any publicly or commercially available STAR-CD "plug-in" user subroutines for the model?


Sebastien Perron August 21, 2000 07:02

Re: Tetrahedral vs. Hexahedral Meshing for CFD
I'm working on a new finite volume methods which allows tet+hex+any kind of elements to solve cfd problems. The results we have got so far tend to show the following things:

-near objects and walls it is far better to use structured meshes (hexahedral meshes ); -the convergence is faster when you use strutured meshes; -in recirculation areas and part of domains which involves changes of direction of the flow, we can obtain better results using unstructured meshes.

As for my self think that the flow tends to follow the mesh. If you use a mesh which doesn't agree with the real flow, you'll obtain solutions that are far from the real ones.

Conclusion: -both kink of elements will help you obtain better results. -but, in general, it is faster to obtain "good" results using hexahedral meshes. - you have to use the mesh which fits best with the flow.

J. Y. Luo August 22, 2000 07:23

Re: Tetrahedral vs. Hexahedral Meshing for CFD
The meshless two layer approach, compatible with the two-layer model, is currently under test as part of STAR-CD V3.20. The idea is to achieve a similar accuracy of simulation to two layer model, but without using actual finer mesh near the wall.

As for the cells with one vertex or edge on the wall, the wall function can be still applied, but it seems the effect is not large. With Tet mesh, aside from the points John mentioned, you also get large Y+ variation (that is to say Y+ could be high-low-high etc) which is not ideal. Touching another point - for hex mesh, it's easy to alian the mesh with flow direction (especially near the wall), thus even use 1st order UD, the artificial diffusion is minimum, this is not the case with TET.

J. Y. Luo August 22, 2000 07:35

Re: Tetrahedral vs. Hexahedral Meshing for CFD
Just a comment about cell with one vertex or edge on the wall. These cells have zero area at the wall, thus in finite-volume approach, they don't contribute to the momentum equations. However, the turbulent wall treatment (whether wall function or lower-reynolds number models) implies that the dissipation rate of turbulent kinetic energy is fixed with certain formula for all wall cells. Now you have a question: do you want to apply this fixed dissipation value to the cells with only a point or edge at the wall?

All times are GMT -4. The time now is 05:29.