Not many people really enjoy meshing. It’s a means to an end. It gets in the way of getting to the answer. So it’s no surprise that when things go wrong, the mesh often gets the blame. In Pointwise’s case, our software gets the blame because we are not tied to one particular solver.

And that’s okay.

That’s why we need to have, at least, a good understanding of the flow solvers our customers use. I’m writing today about an example in which something went wrong and our software – fairly or unfairly – was blamed. I set out to find a solution.

Complex Meshes

A good example of a very complex geometry. Image source: BMI Corporation from FUN3D mailing list

My example requires a little preamble first. You may or may not have heard us making noise about our viscous unstructured boundary layer meshing technique, T-Rex. You can find more specifics about it on our website and we recently hosted a webinar introducing it in Pointwise. The genesis for T-Rex is to be able to reduce the time it takes to generate high-quality boundary layer resolved meshes on complex geometry. When we say high quality, we mean of sufficient quality to, for example, predict the drag on a commercial aircraft. While in general, these meshes are of high-quality, it’s a reality that to automate the meshing process we must accept some compromise. The compromise is that not every single cell will be of high-quality – at times we are left with a handful of poor quality cells. Most modern CFD solvers are robust enough to tolerate a handful of bad cells. When I say a “handful”, I mean on the order of << 1 percent of the total.

Negative Volume Tetrahedron?

Back on point, there’s a subtle issue at hand with these poor quality cells and that’s where my story begins. I was investigating a fairly large mesh (~180 million cells) created by a customer using T-Rex, who, upon importing it into the CFD solver and performing the recommended cell volume check, discovered a few negative volume cells (four to be precise). How could this be? One of the criteria T-Rex uses when generating meshes is to prevent negative volume cells. In the case of a tetrahedron, its volume is always positive because it can never be concave, provided a consistent point orientation is used. So T-Rex doesn’t allow negative volumes, yet the CFD solver volume check is reporting negative volumes. My degree of confusion was increasing.

Inaccuracies of Discrete Mathematics

I explored several avenues, and one in particular looked decidedly suspicious. Could the difference be a result of dissimilar methods of calculating cell volume between Pointwise and the CFD solver? If so, what was the justification?

It just so happens I have a relative working in academia who specializes in the intricate details of numerical methods.  He pointed me to some work by a retired UC Berkley professor, Prof. William Kahan, about the difficulties associated with accurately calculating the area or volume of a highly irregular triangle or tetrahedron. In short, accurately computing the area or volume of highly irregular triangles or tetrahedron is neither obvious nor straightforward. The most challenging irregular cells are of the obtuse type that approach degeneracy.  Obtuse would mean a triangle with one large included dihedral angle or a tetrahedron with two or more.  A degenerate cell would have an included angle of 180, e.g. all four points would be co-planar for a tetrahedron. When I mentioned poor quality cells, I’m referring to those getting close to this limit (>179). So it is possible that sensitivity of the area and volume calculation to round-off error could result in positive volumes with one method and negative volumes with another.

Poorly shaped cells

Engineering Solutions

Until I know the exact implementation of both Pointwise’s and the CFD solver’s volume computation methods, I cannot know for sure if their difference is the cause. The immediate solution I can provide the customer is advice on how to tune several T-Rex parameters to help reduce the number of poor quality cells and thus reduce the chance of encountering negative volumes. Doing so usually comes at the expense of a few T-Rex boundary layers cells, but due to T-Rex’s ability to stop the extrusion front locally, adjusting these parameters does not significantly affect the total number of layers. It’s really a trade-off – more boundary layer cells with more poor quality cells or slightly fewer boundary layer cells with fewer poor quality cells. In the case I referenced above, I was able to reduce the number of poor quality cells from a few thousand to less than a hundred (recall the total cell count was ~180 million). Importing the adjusted mesh into the CFD solver and checking the cell volumes now resulted in no negative volume cells.

Lessons Learned

The important lessons to take away are

1. Numerical methods are used for everything we do. As such, we should have at minimum a basic knowledge of the methods our tools are using.
2. Round-off error is important and can have a significant impact on results. Both developers and users of software need to be cognizant of the presence of round-off errors.  Prof. Kahan is of the general opinion that neither developers nor users are aware of the problem and the issue has been further obfuscated by poor compiler design choices.
3. If the most correct or elegant solution may take some time to elucidate, seek an intermediate solution. Engineering is about compromises and finding solutions to real problems in a timely matter. In my case, I concurrently attempted to find the underlying problem while coming up with a short-term solution. Sometimes, the best answer is the one that works.
4. It would be valuable for mesh generators and flow solvers to use a consistent set of formulae and procedures for computing mesh metrics.

I suspect as engineers continue to push the boundaries of CAE analysis, these types of issues will become more and more frequent.

The specific article regarding the volume of tetrahedron is an interesting read if you have some time: What has the Volume of a Tetrahedron to do with Computer Programming Languages?