Making Sense of CFD Grid Types A CFD grid is essential for every production flow solver that I'm

aware of, but there are a lot of different computational mesh types out there. If you are not that familiar with CFD, it can be a bit bewildering to cut through the jargon and make sense of it all. This page aims to provide a quick introduction to some of the more common terms. Structured Grids The first production codes for solving the Euler or Navier-Stokes equations did so on so-called structured grids. Structure in this case refers to the way the grid information is addressed by the computer. In a structured CFD grid, you can construct a mapping function that will transform a curvilinear mesh (of the physical domain you're interested in) to a uniform Cartesian grid (the way the computer stores the data--see the figure below for an example). This allows a given point's neighbors to be easily identified and efficiently accessed, which allows for speedy CFD codes.

On the other hand, it means that you cannot just plop down additional points into the CFD grid if you decide you need more in some area. The points go into a mesh, and you must add a whole line at a time (in 2-Da plane at a time in 3-D) in order to preserve the structure of the mesh. For example, if you add a point midway between (i,j) and (i+1,j) in the above figure, you must also add points between (i,j+1) and (i+1,j+1), and also between (i,j-1) and (i+1,j-1). Otherwise, middle row of points would have one more than the others, and the mesh structure would be broken. Structured meshes come in three basic flavors: H-grids, O-grids, and C-grids. An O-grid will have lines of points where the last point wraps around and meets the first point (see the figure below). Thus, you'll have some grid lines that looks like the letter 'O'.

A C-grid will have lines of points in one direction which are shaped roughly like the letter C, and one of those lines will typically bend back to meet up with itself at some point. In the example below, the line which describes the airfoil surface meets at the trailing edge. There is, therefore, a slit aft of the trailing edge, where the line leading from the lower surface of the airfoil coincides with the line from the upper surface.

An H-grid is pretty much any structured grid that isn't an O-grid or a C-grid. The first figure above shows two simple H-grids. Multi-Block Grids A multi-block CFD grid is one where the computational domain is made up of more than one computational mesh. There are many reasons why you might want to do this. For example, it is often done so that you can run the case more efficiently in parallel on a multi-processor system. Or maybe there is a tricky portion of the geometry that is better treated with a series of smaller grids rather than one big grid. Whatever reason you might have for using multiple blocks in a computational domain, these blocks will have to talk to each other. There are several different ways to do this. Abutting boundaries occur when two blocks share a common boundary. They may or may not be point-matched along that boundary (i.e. all the boundary points coincide). Obviously, if the grid topology and computational resources permit, a point-matched boundary is better than a non-point-matched boundary. Overlapping boundaries is the term used, as you might guess, to describe blocks that overlap each other to some degree. The boundary points of each block get their information from the interior points of the neighboring block. A point-matched overlapping boundary is a very good way to have blocks interact, but it can be hard to achieve throughout complex domains. CHIMERA refers to a special class of overlapping boundaries where an overlapping grid cuts holes in the interior of an underlying grid. The governing equations are not solved inside these holes and the solution for that portion of the flow comes strictly from the mesh which cut the hole. Unstructured Grids Unstructured CFD grids do not have a direct mapping between where things are in memory and how they connect in the physical space. Unlike structured CFD grids, the cell at location 'n' in memory may have no physical relation to the cell next to it at location 'n+1'. This means that an unstructured solver has to do a bit more work to figure out where neighboring cells are, but it allows for a lot of freedom in constructing a CFD grid. You can add resolution where you need it, and coarsen the grid wherever you don't. Note that you can always convert a structured grid to an unstructured one, but not necessarily the other way around. Using an unstructured approach also frees you from always having to use quadrilaterals (in 2-Dhexahedrons in 3-D) the way you do in structured grids. Some unstructured CFD solvers only work with a single cell type (USM3D, for example, uses only tetrahedra), but most allow you to build grids with different cell shapes (three examples shown below). Some newer unstructured CFD codes even allow you to use n-sided polygons, where the CFD grid can be made up of cells with an arbitrary number of faces.

Another class of unstructured grid is the Unstructured Cartesian mesh. At first glance, that sounds like an oxymoron. After all, the whole point of unstructured grids is to get away from having to deal with the structure implied by the word Cartesian, right? Well, it turns out that you can do Cartesian meshes in an unstructured fashion, and this approach has some real strengths. When building an unstructured Cartesian mesh, you typically start with a few cubic (or square in 2-D) cells (sometimes just one) that cover the full extent of the domain where you wish to compute the flow. Then, these cells are subdivided into smaller cubes until you satisfy some tolerance. The figure below shows a 2-D example of a mesh around a half cylinder.

Note how the cells around the body do not exactly follow the body. This is one of the most striking features of unstructured Cartesian meshes. The solvers which employ this grid technique use immersed boundaries to handle curved surfaces. Thus, all the cells are cubic (or square), and the boundary curvature is handled not with the grid, but inside the solver. The unstructured Cartesian mesh above also illustrates what are called hanging nodes. These occur when a cell on one side of a face boundary is split in half, but its neighbor is not split. As a result, you end up with grid nodes which sit in the middle of a cell face (from the point of view of the neighboringunsplitcell). Some unstructured solvers can handle this sort of configuration, but many cannot. How Should We Then Grid? Unstructured grids offer maximum flexibility: in theory, you can put a grid around anything, no matter how complicated. Also, you only have to put grid resolution where it is actually needed. In a structured grid, because everything is connected together, you often have to cluster points out in the middle of nowhere in order to achieve the resolution you require in other parts of the domain (see the airfoil grid above for an example). Unstructured grids allow you to avoid other undesirable features that frequently pop up with structured grids, So, why would anyone want to use a structured CFD grid? There are several reasons. First, structured solvers generally run much faster than unstructured solvers. Secondly, even though unstructured grids are, in theory, much easier to create, it is often the case that creating a high quality unstructured grid takes about as long as creating a high quality structured grid. Note, however, that it is usually possible to quickly create an unstructured grid that looks passable. You can probably even run it and get some results, but if you dig down and really look at the details, it usually becomes apparent that much more work is needed, and this sort of detail work can take quite a while. Of course, as grid generation technology improves, this issue should recede. Another reason to use structured grids is that unstructured solvers are often (but not always) very dissipative compared to a high resolution structured solver. These schemes are therefore unsuitable for some applications. Also, unstructured CFD codes are almost always no more than second order in space (in current production codes), whereas some production structured solvers have fourth, fifth or sixth order schemes. Why should you care? I've heard it many times from many sources: in general, most of the work of CFD lies in generating the grids. Actually computing the flow and analyzing the results usually takes much less time. There are many reasons for this, but one obvious conclusion is that you need to make sure you are using an appropriate approach for your problem. If you are spending the bulk of your analysis time on CFD grid generation, you want to build the right grid the first time (so you don't have to do it all over again).