Main Page | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members | Related Pages

Mesh

For Finite Element Analysis, the Finite Integration Technique etc. we often need some kind of discretization of the geometry of the given problem. These meshes have to be build with some kind of mesh genrator. There are a lot of mesh generators available on the market which can be used (see the Meshing Software Survey of Steven J. Owen (1998)). But in the end we will need nevertheless a representation of our mesh which fits into our code. This representation is described here.

Since the area of meshes and mesh genration is a very complex thing we restrict ourselves to what we think is important for a basic mesh representation. Further information about meshes and mesh generation can be found e.g. in Joe F. Thompson, Numerical Grid Generation,(1985).

We can devide meshes into structured meshes and unstructured meshes. In The phd-thesis of Steven J. Owen we can find the following definition of these two mesh types: Strictly speaking, a structured mesh can be recognized by all interior nodes of the mesh having an equal number of adjacent elements. Unstructured mesh generation, on the other hand relaxes the node valence requirement, allowing any number of elements to meet at a single node.

structuredmesh.jpg

Structured Mesh

unstructuredmesh.jpg

Unstructured Mesh

meshes are described via elements, which we call primitives in TETlib. Primitives can be points - 0D-elements - to describe the nodes of a mesh, they can be edges - 1D-elements - to describe the edges of a mesh, they can be surfaces like triangles, quadrangles or rectangles - 2D-elements - to describe the surfaces of a mesh, or they can be volumes like tetrahedra or bricks - 3D-elements - to describe the volumes of a mesh.

Each element of a mesh has to be unique, i.e. there has to be a unique address to access a single element. In structured meshes these addresses can be calculated and the elements itself don't have to be stored themselfs, but in unstructured meshes the addresses and the elements have to be stored.

In some algorithms we need access to the neighbors of a cell. Therefore we provide the following definitions of neighbors:

Here are some pictures of structured meshes:

rectangle.jpg

Rectangular Mesh

triangle.jpg

Triangular Mesh

sechseck.jpg

Hexagonal Mesh

3dneighbors.jpg

Brick Mesh

For these kind of structured meshes it is easy to count the number of neighbors:

Surface_Neighbors Edge_Neighbors Corner_Neighbors Neighbors
2D rectangular 0 4 4 4
triangular 0 3 9 12
hexagonal 0 6 0 6
3D brick 6 12 8 26

These meshes will be used for appropiate outer geometries only. The rectangular mesh will be used in a rectangular geometry, the bricks in a brick geometry, the triangular mesh in a triangular geomtry, and the hexagonal mesh could be used for a circle. Therefore the counting is for each mesh something special, in rectangular meshes it is possible via a number of columns and a number of rows to pick any of the rectangles with a pair of indices from the grid. For the circle example the counting is something else but there should also be an algorithm with which each hexagon can be picked from the grid via a pair of indeces.

Since all our TET::Points are cartesian it is also possible to define some kind of order of the neighbours. Perhaps it is nescessary to define a local cartesian coordinate system with its axes parallel to some of the main primitve edges. It is easy to have an order of neighbors for the hexagonal mesh and the rectangular mesh, as can be seen in :

rectangle_number.jpg

Rectangular Mesh

sechseck_number.jpg

Hexagonal Mesh

For triangular grids we have to decide, wether the top is an edge or a corner :

triangle_number_up.jpg

top is a corner

triangle_number_down.jpg

top is an edge

Cartesian Grids

Cartesian grids or better cartesian tensor grids are structured meshes in cartesian coordinates with the edges and/or surfaces parallel to the axes. In Bihn (Zur numerischen Berchnung elastischer Wellen im Zeitbereich, Shaker, (1998))a discretization for volumes is given by

\[ \begin{array}{ccl} G = \{(x_{1,i},x_{2,j},x_{3,k}) \in R^3,&1\leq i\leq I,&x_{1,\nu-1}<x_{1,\nu} ,\\ &1\leq j\leq J,&x_{2,\nu-1}<x_{2,\nu},\\ &1\leq k\leq K,&x_{3,\nu-1}<x_{3,\nu}\quad\}\qquad. \end{array} \]

For the 2D case the third coordinate $ x_3$ is omitted. With this Bihn devides the grids in some special cases:

Rectangular Mesh

If $I$ is the number of columns and $J$ is the number of rows in a given mesh, we can calculate easily the neighbors of a current primitive. The following picture shows an example for $I=6$ and $J=5$.

rectangular_mesh.jpg

indices in rectangular grid

For interior cells there are eight neighbors, as can be seen in the previous picture regarding the colored cells. There are no surface neighbors in the rectangular grid. The numbering of the neighbors depending on the indices of the current cell are given by the following table:



Primitive Indices Example
current i , j 3 , 3
neighbor 1 i-1 , j-1 2 , 2
neighbor 2 i , j-1 3 , 2
neighbor 3 i+1 , j-1 4 , 2
neighbor 4 i+1 , j 4 , 3
neighbor 5 i+1 , j+1 4 , 4
neighbor 6 i , j+1 3 , 4
neighbor 7 i-1 , j+1 2 , 4
neighbor 8 i-1 , j 2 , 3

If the current cell is not an interior cell, i.e. the cell is located at an edge of the mesh or is a corner cell of the mesh, the number of neighbors is of course reduced.



Neighbors Edge_Neighbors Corner_Neighbors
Interior Cell 8 4 4
Edge Cell 5 3 2
Corner Cell 3 2 1

Brick Mesh

Here we display only some figures to explain numbering and directions in the brick mesh. Perhaps we will enlarge this section later.

3dneighbors.jpg

neighbors in a brick mesh

3dbackfront.jpg
html 3dtopbottom.jpg
3dleftright.jpg

What is back, front, etc. layer of a current cube?


Generated on Sun Apr 25 11:56:53 2004 for TETlib by doxygen 1.3.6