244
8. Complex Geometries
of the linear equation solver is then called numerical ineficiency. Schreck
and PeriC (1993) and Seidl et al. (1996), among others, have performed numerous tests and found that the performance - especially when conjugate
gradients and multigrid solvers are used - remains very good even for a large
number of sub-domains. When a good structured grid can be constructed, it
should be used. Block-structuring does increase the computing effort, but it
allows solution of more complex problems and it certainly requires a more
complicated algorithm.
An example of the application of this approach is presented in Sect. 8.11.
An implementation of the algorithm for 0 - and C-type grids is found in the
code caffa.f in directory 2dgl; see Appendix A.1. Further details of the
implementation for block-structured non-matching grids is available in Lilek
et al. (1997b).
8.6.6 Unstructured Grids
Unstructured grids allow great flexibility in adapting the grid t o domain
boundaries. In general, control volumes of arbitrary shape, i.e. with any number of cell faces, can be used. However, grids with mixed CV types are not
common; usually, triangles or quadrilaterals are used in 2D and tetrahedra
or hexahedra in 3D. Prisms, pyramids, and tetrahedra may be considered
special cases of hexahedra so nominally hexahedral grids may include CVs
with less than six faces.
The data structure depends on CVs used. The main objects are the CVs
and cell vertices. When a grid is generated, a list of vertices is created. Each
CV is defined by four or eight vertices, so the list of CVs also contains a list of
associated vertices. The order of the vertices in the list represents the relative
positions of the cell faces; e.g., first four vertices of a hexahedral CV define
the bottom face and the last four the top face, see Fig. 8.12. The positions of
the six neighbor CVs is also implicitly defined; e.g., the bottom face defined
by vertices 1, 2, 3 and 4 is common to neighbor CV number 1, etc. This is
usually adopted in order to reduce the number of arrays necessary for the
definition of connectivity between CVs.
One needs also to create a list of cell faces. Such a list is easily defined
once the list of CVs and vertices exists, since each face of a CV appears
exactly once in another CV, i.e. if all CVs are scanned, the faces defined by
the same vertices appear twice. It is only important that the vertices that
define a cell face are always ordered in either clockwise or counter-clockwise
order. The same information is contained in the list of faces as that described
in preceding section for block interfaces.
Another possibility is to introduce object oriented data structure and define objects vertex, edge, face and volume. Edges are defined by the vertices
on either end, faces by lists of edges (which must form a closed polygon),
and volumes by lists of faces. The discretization requires approximations to
surface and volume integrals; it makes sense to compute these separately.
8. Complex Geometries
of the linear equation solver is then called numerical ineficiency. Schreck
and PeriC (1993) and Seidl et al. (1996), among others, have performed numerous tests and found that the performance - especially when conjugate
gradients and multigrid solvers are used - remains very good even for a large
number of sub-domains. When a good structured grid can be constructed, it
should be used. Block-structuring does increase the computing effort, but it
allows solution of more complex problems and it certainly requires a more
complicated algorithm.
An example of the application of this approach is presented in Sect. 8.11.
An implementation of the algorithm for 0 - and C-type grids is found in the
code caffa.f in directory 2dgl; see Appendix A.1. Further details of the
implementation for block-structured non-matching grids is available in Lilek
et al. (1997b).
8.6.6 Unstructured Grids
Unstructured grids allow great flexibility in adapting the grid t o domain
boundaries. In general, control volumes of arbitrary shape, i.e. with any number of cell faces, can be used. However, grids with mixed CV types are not
common; usually, triangles or quadrilaterals are used in 2D and tetrahedra
or hexahedra in 3D. Prisms, pyramids, and tetrahedra may be considered
special cases of hexahedra so nominally hexahedral grids may include CVs
with less than six faces.
The data structure depends on CVs used. The main objects are the CVs
and cell vertices. When a grid is generated, a list of vertices is created. Each
CV is defined by four or eight vertices, so the list of CVs also contains a list of
associated vertices. The order of the vertices in the list represents the relative
positions of the cell faces; e.g., first four vertices of a hexahedral CV define
the bottom face and the last four the top face, see Fig. 8.12. The positions of
the six neighbor CVs is also implicitly defined; e.g., the bottom face defined
by vertices 1, 2, 3 and 4 is common to neighbor CV number 1, etc. This is
usually adopted in order to reduce the number of arrays necessary for the
definition of connectivity between CVs.
One needs also to create a list of cell faces. Such a list is easily defined
once the list of CVs and vertices exists, since each face of a CV appears
exactly once in another CV, i.e. if all CVs are scanned, the faces defined by
the same vertices appear twice. It is only important that the vertices that
define a cell face are always ordered in either clockwise or counter-clockwise
order. The same information is contained in the list of faces as that described
in preceding section for block interfaces.
Another possibility is to introduce object oriented data structure and define objects vertex, edge, face and volume. Edges are defined by the vertices
on either end, faces by lists of edges (which must form a closed polygon),
and volumes by lists of faces. The discretization requires approximations to
surface and volume integrals; it makes sense to compute these separately.