“We know embarrassingly little about how the mesh affects the CFD solution,” said Professor Carl Ollivier-Gooch of the University of British Columbia.
That statement is counter to what we all know to be true in practice, that a good mesh helps the computational fluid dynamics (CFD) solver converge to the correct answer while minimizing the computer resources expended. Stated differently, most every decent solver will yield an accurate answer with a good mesh, but it takes the most robust of solvers to get an answer on a bad mesh.
The crux of the issue is what precisely is meant by “a good mesh.” Syracuse University's Professor John Dannenhoffer points out that we are much better at identifying a bad mesh than we are at judging a good one. Distinguishing good from bad is clouded by the fact that badness is a black-white determination of whether the mesh will run or not. (Badness often only means whether there are any negative volume cells.) On the other hand, goodness is all shades of gray – there are good meshes and there are better meshes.
Neither is goodness all about the mesh. Gone are the days when one could eyeball the mesh and make a good/bad judgment. Adaptive meshes that are justified by visual inspection of how much thinner shock waves are in a contour plot of density just do not make the grade. What matters is how accurately the CFD solution reflects reality. Therefore, the solver's numerical algorithm and the physics of the flow to be computed also have to be accounted for in the evaluation of a mesh.
Implicit in the paragraphs above is the idea of judging mesh quality in advance of computing the CFD solution. There are those who think that a priori mesh quality assessment is of limited value and that changing the mesh in response to the developing flow solution (via mesh adaption or adjoint methods or other technology) is the better way to generate a good mesh and an accurate solution.
Given this state of affairs, it was important to assemble mesh generation researchers and practitioners to assess the topic of mesh quality. Pointwise participated in the “Mesh Quality/Resolution, Practice, Current Research, and Future Directions Workshop” last summer in Dayton and hosted by the DoD High Performance Computing Modernization Program (HPCMO) and organized by the PETTT Program (User Productivity, Enhancement, Technology Transfer and Training) and AIAA's MVCE Technical Committee (Meshing, Visualization, and Computational Environments).
The workshop brought together all the stakeholders of mesh quality: CFD practitioners, CFD researchers, CFD solver code developers (both commercial and government) and mesh generation software developers. A list of the workshop presentations is included at the end of this article (References 1a-1i). Hugh Thornburg from High Performance Technologies wrote an overview of the workshop (Reference 2) that nicely sums up the current state of affairs:
Thornburg also offers Simpson's Verdict library (Reference 3) as a de facto reference that covers “most if not all commonly used techniques” for computing element properties.
The importance of a priori indicators of mesh quality is exemplified by NASA's Stephen Alter, who defined and demonstrated the utility of his GQ (grid quality) metric that combines both orthogonality and stretching into a single number. Driven by the desire to ensure the accuracy of supersonic flow solutions over blunt bodies computed using a thin layer Navier-Stokes solver, he has established criteria for the GQ metric that give him confidence prior to starting a CFD solution.
Two aspects of GQ are notable. First, this metric's reliance on orthogonality is closely coupled to the numerics of the solver – TLNS assumptions break down when the grid lacks orthogonality. Second, use of a global metric aids decision making, or as Thornburg wrote, “A local error estimate is of little use.” GQ represents domain expertise – the use of specific criteria within a specific application domain.
Dannenhoffer reported on an extensive benchmark study that involved parametric variation of a structured grid's quality for a 5 degree double-wedge airfoil in Mach 2 inviscid flow at 3 degrees angle of attack. Variations of the mesh included resolution, aspect ratio, clustering, skew, taper, and wiggle (using the Verdict definitions).
Dannenhoffer's main conclusion was very interesting: there was little (if any) correlation between the grid metrics and solution accuracy. This may have been exacerbated by the fact that he found it difficult to change one metric without influencing another (e.g. adding wiggle to the mesh also affected skew) or it may have been due to the specific flow conditions.
Dannenhoffer also introduced the concept of grid validity (as opposed to grid quality), which is intended to measure whether the grid conforms to the configuration being modeled (which in practice it sometimes does not). He proposed three types of validity checks:
Professor Christopher Roy from Virginia Tech showed a counter-intuitive example (at least from the standpoint of a priori metrics) that the solution of 2D Burger's equation on an adapted mesh (with cells of widely varying skew, aspect ratio, and other metrics) has much less discretization error than the solution on a mesh of perfect squares. From this example alone, it is clear that metrics based solely on cell geometry are not good indicators of mesh quality as it pertains to solution accuracy.
The workshop was fortunate to have the participation of several flow solver developers, who shared details about how their solver is affected by mesh quality. The common thread among all was that convergence and stability are more directly affected by mesh quality than solution accuracy.
Metacomp Technologies' Vinit Gupta cited cell skewness and cell size variation as two quality issues to be aware of for structured grids. In particular, grid refinement across block boundaries in the far field where gradients are low has a strong, negative impact on convergence. For unstructured and hybrid meshes, anisotropic tets in the boundary layer and the transition from prisms to tets outside the boundary layer also can be problematic.
Gupta also pointed out two problems associated with metric computations. Cell volume computations that rely on a decomposition of a cell into tets are not unique and depend on the manner of decomposition. Therefore, volume (or any measure that relies on volume) reported by one program may differ from that reported by another. Similarly, face normal computations for anything but a triangle are not unique and also may differ from program to program. (This is a scenario we have often encountered at Pointwise when there is a disagreement with a solver vendor over a cell's volume that turns out to be the result of different computation methods.)
ANSYS' Konstantine Kourbatski showed how cell shapes that differ from perfect (dot product of face normal vector with vector connecting adjacent cell centers) make the system of equations stiffer slowing convergence. He then introduced metrics, Orthogonal Quality and two skewness definitions, with rules of thumb for the Fluent solver. It was interesting to note that the orthogonality measure ranges from 0 (bad) to 1 (good) whereas the skewness metric is directly opposite: 0 is good and 1 is bad. Another example of a metric criterion was that aspect ratios should be kept to less than 5 in the bulk flow. Kourbatski also provided guidelines for the CFX solver.
He also pointed out that resolution of critical flow features (e.g. shear layers, shock waves) is vital to an accurate solution and that bad cells in benign flow regions usually do not have a significant effect on the solution.
Kestrel, the CFD solver from the CREATE-AV program, was represented by David McDaniel from the University of Alabama at Birmingham. At the start, he made two important statements. First, their goal is to “do well with the mesh given to us.” (This is similar to Pointwise's approach to dealing with CAD geometry – do the absolute best with the geometry provided.) Second, he notes that mixed-element unstructured meshes (their primary type) are terrible according to traditional mesh metrics, despite being known to yield accurate results. This same observation is true for adaptive meshes and meshes distorted by the relative motion of bodies within a mesh (e.g. flaps deflecting, stores dropping).
More significantly, McDaniel notes a “scary” interdependence between solver discretization and mesh geometry by recalling Mavriplis' paper on the drag prediction workshop (Reference 4) in which two extremely similar meshes yielded vastly different results with multiple solvers.
To address mesh quality, Kestrel's developers have implemented non-dimensional quality metrics that are both local and global and that are consistent in the sense that 0 always means bad and 1 always means good. The metrics important to Kestrel are an area-weighted measure of quad face planarity, an interesting measure of flow alignment with the nearest solid boundary, a least squares gradient that accounts for the orientation and proximity of neighbor cell centroids, smoothness, spacing and isotropy.
Differing from Dannenhoffer's result, McDaniel showed a correlation of mesh quality with solution accuracy with the caveat that a well resolved mesh can have poor quality and still produce a good answer. (In other words, more points always is better.)
Alan Mueller's presentation on CD-adapco's STAR-CCM+ solver began by pointing out that mesh quality begins with CAD geometry quality and manifests as either a low quality surface mesh or an inaccurate representation of the true shape. This echoes Dannenhoffer's grid validity idea.
After introducing a list of their quality metrics, Mueller makes the following statement, “Results on less than perfect meshes are essentially the same (drag and lift) as on meshes where considerable resources were spent to eliminate the poor cells in the mesh.” Here we note that the objective functions are integrated quantities (drag and lift,) instead of distributed data like pressure profiles. After all, integrated quantities are the type of engineering data we want to get from CFD.
This insensitivity of accuracy to mesh quality supports Mueller's position that poor cell quality is a stability issue. Accordingly, the approach with STAR-CCM+ is to be conservative – opt for robustness over accuracy. Specifically, they are looking for metrics that will result in division by zero in the solver. Skewness as it effects diffusion flux and linearization is one such example.
Dr. John Steinbrenner and Nick Wyman shared Pointwise's perspective on solution-independent quality metrics by taking a counter-intuitive approach. You would think that a mesh generation developer would promote the efficacy of a priori metrics. But the error in a CFD solution consists of geometric errors, discretization errors, and modeling errors. Geometric errors are similar to points made by Dannenhoffer and Mueller about properly representing the shape. Modeling errors come from turbulence, chemical, and thermophysical properties. Discretization involves degradation of the solver's numerics. The discretization error is driven by coupling between the mesh and the solver's numerical algorithm.
Therefore, although Pointwise can compute and display many metrics, it is important to note that many of them lack a direct relationship to the solver's numerics and accordingly they are only loose indicators of solution accuracy. On the other hand, these metrics are convenient to compute, can address Dannenhoffer's grid validity issue, and provide a mechanism for launching mesh improvement techniques. They also form the basis of a user's ability to develop domain expertise – metrics that correlate to their specific application domain.
Find out how many minutes it takes to generate your mesh using a demo license of Pointwise. Start the process today.
3rd Quarter of 2017
2nd Quarter of 2017
May 2017, Special Edition
1st Quarter of 2017
December 2016, Special Edition
4th Quarter of 2016
September 2016, Special Edition
3rd Quarter of 2016
2nd Quarter of 2016
1st Quarter of 2016
February 2016, Special Edition
November / December 2015
September 2015, Special Edition
September / October 2015
July / August 2015
June 2015, Special Edition
May 2015, Special Edition
May / June 2015
March / April 2015
February 2015, Special Edition
January / February 2015
November / December 2014
September / October 2014
August 2014, Special Edition
July / August 2014
May / June 2014
April 2014, Special Edition
March / April 2014
January / February 2014
November / December 2013
September 2013, Special Edition
September / October 2013
July / August 2013
June 2013, Special Edition
May / June 2013
March / April 2013
February 2013, Special Edition
January / February 2013
December 2012, Special Edition
November / December 2012
September / October 2012
August 2012, Special Edition
July / August 2012
May / June 2012
March / April 2012
March 2012, Special Edition
January / February 2012
November / December 2011
September / October 2011
July / August 2011
May / June 2011
March / April 2011
January / February 2011