UNSTRUCTURED MESH SOLVER FOR THE CONVECTION DIFFUSION EQUATION

Zachary A. Sterba Department of Mechanical Engineering Purdue University West Lafayette, Indiana Email: [email protected]

Hongwei Li Department of Mechanical Engineering Purdue University West Lafayette, Indiana Email: [email protected]

ABSTRACT The steady-state convection-diffusion equation is solved on a non-orthogonal unstructured mesh using the upwind difference method and the finite volume scheme. A Fortran90 code loads a two-dimensional mesh of arbitrary shape containing cells of any polygonal shape, or a mixture of several polygonal shapes. Data structures used are chosen with much attention given to memory and computational efficiency. This mesh is then solved for a test case of uniform flow, where Dirichlet boundary conditions are specified, and the high Peclet number assumption is specified at the output. It is then demonstrated that the solution corresponds to a uniform mesh solution of the same problem. The solver is then tested on a large mesh with irregular boundaries, and a mixture of cell geometries to demonstrate its ability to handle highly complicated input. The convergence of this large mesh was unacceptably slow, demonstrating that any future work will demand a faster and more sophisticated solution scheme. NOMENCLATURE ap ,anb matrix coefficient at a cell and its neighbor Af face area vector b forcing term gradient vector resulting from least squares fit b Df diffusion term keeps track of whether the normal vector of face n Dirn points into or out of the cell in question e unit vector in the cell centroid to cell centroid direction f a cells face; all faces of a cell Ff convection term gradient coefficient matrix G J flux vector h synonymous with i, j unit vectors in the x- and y-directions nb a cells neighbor; all neighbors of a cell face area (i.e. length) vector in two-dimensions L geometry matrix for least squares fit M S source term 1

Tp, Tnb T V Vb Vend n X, Y V

function value (i.e. temperature) at a cell and its neighbor function value vector for use in least squares fit velocity vector boundary velocity vector the index of vertex at end n of a face where n is 1 or 2 is useful in linking cells and faces centroid location distance between cells the volume of one cell diffusion coefficient vertex-to-vertex direction cell centroid to cell centroid direction density secondary gradient term

MOTIVATION Finite volume models generally use one of two mesh types; these types are characterized by cell connectivity. Structured meshes have a regular, predictable connectivity where all grid points have the same number of neighbors (Figs. 1a, 1b). Unstructured meshes, however, allow a grid point to have any number of neighbors (fig. 1c) (Owen). Triangles and quadrilaterals are most common cells shapes used in two dimensional unstructured meshes, though polygons of any number of sides could be encountered. Structured meshes have advantages in their ease of generation and the simplicity of the models which use them. Unstructured meshes have certain other advantages. They can be flexibly fit to complicated domains. Elements can be rapidly graded from small to large, and such meshes are relatively easy to refine and de-refine (Bern 2000). A structured mesh can be drawn for an irregular geometry as in Fig. 1b. Such a mesh is, however, likely to produce highly skewed cells. This results in large secondary gradients, which slow the path to solution when using finite volume and finite difference methods (Murthy, 2002). This underscores the need for a routine which can handle such methods.

Interior Region The 2-D steady convection-diffusion scalar transport governing equation can be expressed as

J = S
where J is given by
Figure 1a. A regular boundary allows for an un-skewed structured mesh

(1)

J = VT T

(2)

where the velocity field is assumed as known at all the requisite points in the domain. Boundary Conditions At Dirichlet inflow boundary conditions

V = Vb and T = Tgiven

(3)

Figure 1b. An irregular boundary results in a highly skewed structured mesh

At the outlet boundary, a high Peclet number condition is used. This assumes that there is no diffusion across the boundary. NUMERICAL APPROACH This approach for solving the two-dimensional governing steady scalar transport equation follows Murthys course notes (2002). There are three common discretization methods which would work for the governing equation on an unstructured mesh: the finite difference, finite volume and finite element method. The finite volume method, which guarantees continuity, is applied in this project. In this method, the physical domain is split up into small control volumes and the partial differential equations are integrated over each volume. Equation 1 is integrated over the cell of interest as:

Figure 1c. An unstructured mesh on the same domain is much less skewed

GOVERNING EQUATIONS Assumptions, Simplifications and Limitations Several simplifications are made in order to allow this exercise to focus on the stated problem, rather than writing subroutines to parse large input tables. A uniform flow field is chosen for this model since generating and inputting a non-uniform flow field on such a mesh would be cumbersome. Many interesting problems and test have uniform flow fields, so the model will still be useful with this simplification. The body source term is ignored for similar reasons. Additionally, the model only handles Dirichlet boundary conditions. This is a more serious constraint, but it substantially reduced program input needs, especially when considering convection. Finally, uniform fluid density and conductivity are assumed. This is not a bad assumption for a steady-state model of a fluid in convection, since in a physical case these properties convect with the fluid. If they were not uniform in space, the problem would become time dependent. 2

JdV = SdV
V

(4)

Discretization Assuming a linear source term, the divergence theorem is applied to Eq. 4 obtaining

J
f

A f = SV0

(5)

Expanding with Eq. 2 yields

(6)

By approximating with the Upwind Difference Scheme (UDS), the discretized equation for a cell becomes
a pTp = anbTnb + b
nb

(7)

where
a = D + Max[ F ,0] f f nb a P = anb S P V0 + F f nb f b = SV ( ) f nb 0 nb

(8)

The diffusion term at a face can be found by

(9)

Boundary Conditions Inflow boundaries Dirichlet inflow boundaries behave much like cells in the interior of the domain. The difference is that one or more of the neighbor cell temperature values are replaced with the given boundary temperature values. Care must be taken in computing the cell to cell vectors, as one of the cells is now a boundary wall. Outflow boundaries Since UDS is being used and high Peclet number assumption removes diffusion across the boundary, downstream boundaries can safely be ignored. A cell at the downstream edge is only influenced by other cells in the domain. Computation of Gradients It is essential to know the function gradient at each cell. Not only is this useful in finding the secondary gradient term, but in many problems the gradient of a potential, not the potential itself, is what is interesting. The least squares method, with proper precomputation seems to give a good balance of accuracy and computational efficiency. This method can be expressed as
M T MT = M T T

The convection term at a face can be found by

(12)

(10)

where
xnb ,1 Tnb ,1 T p x T T nb , 2 nb ,1 p and M= T= Tnb , N T p xnb , N ynb ,1 ynb ,1 ynb ,1

The secondary gradient accounts for the possibility that the face normal may differ from the vector connecting two cell centroids. This happens on a non-orthogonal mesh.
f = f (T ) f A f + f A f A f A f e (T ) f e

(13)

(11)

This requires computing the temperature gradient at a face. The mean of the gradients in the adjacent cells is simply used.

The matrix M depends on geometry alone and thus all operations involving it can be pre-computed for each cell. The gradient computation At each iteration is reduced to
T = GT

(14)

Where the pre-computed G can be found by

G = M TM

MT

(15)

Figure 2. The geometry of one cell interface (adapted from Murthy)

DATA STRUCTURES Given the virtues of an unstructured mesh one might wonder why structured meshes are ever considered at all for problems of possibly irregular boundary shape. The answer quickly becomes apparent to the programmer of an unstructured model, as the data structures used to store such a model are vastly more complicated and cumbersome than those of a structured model. In an unstructured model, a cell 3

may connect to any number of other cells, and these connections all have to be stored in memory, and have to be accounted for even the most trivial of computations. A system of face-based storage is used, where values relevant at faces, such as face length, cell spacing, and diffusion and convection terms are stored on face objects (Fig. 4). Values relevant at cell centroids, such as cell area, and function value, are stored on separate cell objects (Fig . 6). The cell data type must also include an array to keep track of whether the adjoining faces normals point into or out of it. This avoids redundancy in the stored data, saving memory and more importantly reducing update times, as these values only have to be assigned once. In addition, each face object must keep track of its adjoining cells, and each cell object must keep track of its adjoining faces and cells. The most computationally efficient way to do this is with pointers. A pointer is a variable which, instead of storing a piece of data, stores the address where that piece of data can be found in computer memory. Using pointers is a very fast and efficient way for objects to store their connections to other objects. Thus each face contains the memory address of its two adjoining cells, while each cell contains the memory address of each of its neighbor cells and faces.
Cell Neighbor 3 Cell Neighbor 2 Face Neighbor 2

Ln V2 X2 , Y2

Cell Neighbor 2

e
X, Y

Cell Neighbor 1

V1 X1 , Y1

Figure 5 Geometric connections of a face

Lj ej Y YEnd 1 YEnd 2

XEnd 1 XEnd 2

Cell Below Face

Face Neighbor 3

X, Y

Cell Neighbor 1

C2
C

Cell Above Face

Face Neighbor 4 Cell Neighbor 4 Face Neighbor 1

Figure 6 Face data structure

Figure 3 Geometric connections of a cell

Number of Neighbors etc. F1 Face Neighbor 1 F2 Face Neighbor 2 Face Neighbor N

Ignoring boundary conditions, each cell can have between three and an infinite number of neighbors (though it is unlikely to have more than seven or so). Therefore the data structures storing these pointers must be allocatable at runtime so they can be sized to the proper number of neighbors. Additionally, it would be convenient to store all of the cell objects in an allocatable array and all of the face objects likewise. This allows the program to handle meshes of various sizes without wasting memory with large, empty pre-allocated arrays. PROGRAM OVERVIEW The program was written in Fortran90. It took input from a series of plaintext files, and outputted results to an other plaintext file. A program flowchart can be found in Appendix A. Complete annotated source code can be found in Appendix B. The code itself does not generate meshes, as that is a difficult problem in and of itself, perhaps more difficult than 4

Dir1

C1
C

Cell Neighbor 1

Dir2

C2
C

Cell Neighbor 2 Cell Neighbor N

FN
F

DirN

CN
C

Figure 4

Cell data structure

solving a system on the generated meshes. Instead, meshes are generated using Fluent Gambit. A subroutine parses the Gambit output and saves it in memory. The cell array is allocated the appropriate size, and the cell elements are created from the gambit output. The subroutine creates each face object for each cell, checking a table of already created faces to prevent double-creating face objects. Since the number of faces is not known until all faces have been created, the face array must be capable of being resized multiple times at runtime. The subroutine also links together cells and faces by assigning their pointer values. Next, boundary values are loaded from a second file. A series of boundary cells is created and linked in a fashion similar to the interior cells. It is convenient to use the same type of cell object for boundary cells, to permit any pointer to be able to point to either. After loading boundaries, a subroutine is called to compute geometries and other characteristics of cells and faces. The values computed for cells include areas and centroids. Those for the faces include centroids, cell-to-cell vector components, area vector components, and diffusion and convection terms. As mentioned above, a matrix can be pre-computed to speed the computation of gradients. A subroutine is called to perform the matrix operations to compute this matrix, and to compute several values which aid in computing secondary gradients when the gradients at centroids are known. The system is now solved using Gauss-Seidel iteration. At each iteration, three steps are taken. First, gradients at cell centroids are found using the current solution values. Second, secondary gradients are computed using the updated gradients. Third, with all terms now updated the solution at each cell is updated using Eq. 7. This involves looping over each face of each cell to sum up coefficients. Finally the results are outputted to a file. All dynamic memory not previously de-allocated is de-allocated now. VALIDATION Solution Validation Although unstructured meshes are ideal for irregular geometries, it is desirable to validate the unstructured mesh solver on a regular shaped domain. In this case, a square with a side length of three units was chosen. This domain is discretized into an unstructured mesh containing 28 nonorthogonal triangular cells. Density and conductivity are both set to unity. The velocity field is set such that at all points there is an x-velocity with a magnitude of one, and no yvelocity. The upstream wall is set to a temperature of one, and all other walls are given a temperature of zero.

T=0 T=1 V=i T=0 3

T=0 3

Figure 7 Solution validation test case

The model is set to iterate until an absolute convergence of 10-7 is achieved. The output is compared to that of a structured mesh solver for the same problem. The structured mesh solver was written for a class exercise and has been confirmed to produce valid solutions. A structured mesh of 50 by 50 cells was used. The results are compared in Fig. 8.
1.5
0 .1 0.2

0.1
0.3
0.5
4 0.

1
0.8

0.4 0.6 0.7

0.2

0.5

0.9

0.3

0.7

0.5
0.4
0.3

-0.5
0.8

0.6

0.9 -1 -1.5 -1.5

0.2

5 0. 0.3

0.2

0.1 0 0.5 1 1.5

-1

-0.5

Figure 8a Unstructured mesh solution using 28 triangular cells

0.2
0.3

0.1

6 0. 0.8 .9 0

0. 5
0.7

0.2

0.5

0.4

0.6

0.8

0.9

-0.5

0.7

0 .5

0.3

6 0.

0.4

0.2

-1
0.8
0.5
0.1 -1

0.3 0.2
0.1

.4 -1.5 0.90.3 00.2 -1.5

-0.5

0.5

1.5

Figure 8b Structured mesh solution using a 2500 cell square grid and a previously validated structured mesh solver

Bearing in mind that the structured mesh contains more cells by two orders of magnitude, the two mesh solutions correspond quite neatly. Mesh Handling Validation It is also important to confirm that the program can input and solve large, irregular meshes, with a mixture of element geometries. A mesh with approximately 104 cells is used for this test case. Its boundary is an irregular concave polygon, and it is discretized using both triangles and quadrilaterals. Dirichlet boundary conditions ranging from zero to one are arbitrarily placed around the outside of the mesh. The solution of this problem is not known before hand, so the purpose of this investigation is simply to confirm that the program can load such a mesh and a solution can be found. The program had no trouble quickly and efficiently loading the mesh into memory, however, convergence to solution was unacceptably slow. An absolute convergence of 10-5 can be achieved with approximately 3 minutes of computation time on a single Sun 1.3 GHz UltraSPARC-IIIi processor. This is no doubt due to the use of Gauss-Seidel iteration on an unsorted mesh, as that scheme gives notoriously slow convergence on meshes. A future implementation should use a more sophisticated scheme to give faster convergence as is described below.

3
0.8

0 .6

0.3
0.8
0.2

0.5
5 0.6 0. 0.7 0.1

0.7

0.4

0.9

0.5

0.8
0.7 0

0.9 0.1 2 3 4

X Figure 9b Solution on large, irregular validation mesh

X Figure 9a Large, irregular validation mesh

POSSIBLE FUTURE EXTENSIONS Naturally, the code should be made more flexible, permitting the use of Neumann and mixed boundary conditions, a source field, and a non-uniform flow field. To do this, the actual computation would remain essentially unchanged. However, subroutines to parse several more input files would be required, and the cell objects would require minor modification by adding fields to hold velocity and source values. The greatest cost of these modifications would be the time and effort required to generate source and velocity input tables for unstructured meshes. This would probably require a second program for all but the simplest meshes. Convergence rate is a more serious issue with no easy solution. Several steps could be taken to reduce computation and speed convergence. First, the cells are loaded and stored in no particular order. If they were sorted, the advantages of Gauss-Seidel iteration over Jacobi iteration would be more significant. This would involve writing one or more routines to sort the cells by position. Efficient sorts algorithms such as the merge sort are recursive divide-and-conquer schemes. Fortran90 does not support recursion, so any recursive routine involves writing a stack, which is no easy undertaking. Much more substantial improvements can be seen with schemes based on the line-by-line tri-diagonal matrix algorithm (LBLTDMA). While this method is usually only seen with structured meshes, it can be adapted to function on structured meshes. To do so, a cell along a boundary is first selected, and is linked to a neighbor. This process is repeated, forming a chain, and the process stops when the chain reaches the opposite end of the domain. By judiciously choosing which neighbor to link each cell to, chains may be constructed which run in a desired direction. Other chains are constructed in a similar way until all cells are part of a chain. This method is even less suitable for Fortran, as it requires three sorts: One 6

0.5

0.5

0.3

0.6

0.1

0.4

0.9

to find the leftmost points to start chains, one to find the best neighbor to link onto the chain, and one to sort the chains once they have all been created. The programmer of such a scheme would be strongly advised to use a language such as C++ which has built-in recursion support. By creating a second set of chains which generally run in an orthogonal direction to the first, an alternating LBLTDMA or whirlpool scheme can be created.

REFERENCES [1] Owen, S., A survey of unstructured mesh generation technology. Ansys Inc. [2] Bern M., Plassmann P.E., 2000, Mesh Generation. [3] Murthy, J. Y., 2002, Unpublished Course Notes, Numerical methods in heat, mass and momentum transfer.

(a)

(b)

Figure 10 Horizontal (a) and vertical (b) LBLTDMA chains on an unstructured mesh

An algebraic multi-grid scheme would also dramatically speed convergence. This scheme is recursive in nature, which again makes languages like C++ desirable for implementing it. There is also a concern of determining which equations to agglomerate together, which could be a complicated problem. CONCLUSION While unstructured meshes are highly useful for discretizing irregularly shaped domains, this exercise demonstrated several of their drawbacks. Efficiently storing data requires complicated linked data structures. Secondary gradients slow convergence in the same way that nonlinear terms do. To make matters worse, schemes like LBLTDMA which are simple to implement on structured meshes become treacherous to implement on unstructured meshes.

APPENDIX A SIMPLIFIED PROGRAM FLOWCHART

Load input file names Compute grid geometry Cell centroids Cell areas Face length components Face centers Cell spacing components D and F values

Read material and flow properties

Load the grid Read vertex coordinate table

Read cell vertex table

Search for which faces of cell are not yet generated Generate the others

Pre-compute gradient coefficients For finding gradient of U at cell centurions For finding secondary gradient from gradient of U Solve with Gauss-Seidel Compute gradients using pre-computed coefficients Compute secondary gradients using precomputed coefficients

Link cell to faces

Link faces to cell

Load Boundary Conditions Read BC vertex table

Find U at each cell from coefficients and neighbor values

Create boundary cell

Output solution

Search for neighbor face

De-allocate dynamic memory

Link boundary cell to face

APPENDIX B SOURCE CODE The program is written in Fortran90 and was compiled using a Sun Studio Fortran compiler running on SPARC hardware.

Type PROGRAM SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE SUBROUTINE MODULE MODULE MODULE

Program Unit uns loadparameters loadproperties loadgrid resizef loadbc computegeometry precomputegradients solve output garbagecollect moduns modparams modsolveparams

Description Main unstructured mesh convection-diffusion solver Loads input parameters from a file Loads the fluid/material properties and fluid velocity from a file Loads the mesh data from a file and constructs the mesh in memory Resizes the vector holding face objects Loads the boundary cells from a file Computes cell and face geometries and other parameters Pre-computes matrix used in finding gradients Solves the resulting system with Gauss-Seidel iteration Outputs results to a file De-allocates all dynamic memory Defines and holds cell, face, and boundary cell data structures Holds names of input files Holds parameters useful at solve time

Page 10 11 12 13 18 20 22 25 28 31 32 33 35 35

Source code has been omitted.