Meshing: The Chronic Pain of CFD Engineers

There are very few topics in CFD that trigger stronger opinions than meshing.

On one side, there are high-quality structured or block-structured meshes generated with tools such as GridPro, very often regarded as the gold standard for accuracy and robustness.

On the other side, you have unstructured or hex-dominant meshers, such as snappyHexMesh OpenFOAM’s built-in hex-dominant mesher. It is flexible, can be easily automated, and often overlooked/criticized.

This post is not about declaring a winner, but rather explaining the types of applications in industry where a mesher like snappyHexMesh can still be useful, despite its well-known limitations.

I know there are a large number of meshers out there—most notably Pointwise, cfMesh, ANSYS ICEM CFD, Siemens Simcenter STAR-CCM+ Mesher, Altair HyperMesh, ANSYS CFX, Gmsh, and SALOME—you name it.

Although I have used some of these meshers over the years (and am currently learning cfMesh as a more robust alternative to snappyHexMesh), this post will focus on GridPro and snappyHexMesh—two meshers with which I have the most experience, and which sit at opposite ends of the mesher spectrum.

GridPro vs snappyHexMesh. Yes, the left one is better.

What GridPro is good for?

There is no question that fully-structured meshes you can obtain with GridPro offer exceptional mesh quality.

The key strengths of GridPro meshes are:

• Fully structured topology
• Excellent control over cell alignment (we all like flow-aligned meshes)
• Very low numerical diffusion (see above)
• High-quality boundary layers

For application where geometry changes are limited, near-wall accuracy is important, and creating the absolute best mesh beats productionizing your cases, GridPro meshes are hard to beat. In many academic and high-fidelity industrial applications, GridPro remains the gold standard.

However, there is no free meal

The same properties that make GridPro meshes excellent also makes them quite rigid.

• Very steep learning curve, which creates high dependency on meshing expertise
• It is a significant challenge and manual effort to build and maintain topologies
• Commercial, licensed software where you pay for a single license-single run basis, which can constrain scalability across teams and large parametric studies

When your geometry evolves slowly and you have a few cases where you want the absolute best mesh, this is acceptable.

When your geometry evolves constantly and you want short turnaround time generating new cases, this becomes a bottleneck.

How does snappyHexMesh factor in?

snappyHexMesh is a different tool that optimizes for a different objective.

It does not provide elegant meshes, or perfect topology, but it provides:

• no license (very easy to scale up production)
• automation
• flexibility
• easy integration with OpenFOAM workflows (heck, it is part of OpenFOAM!)

The key advantages of snappyHexMesh are:

• there is minimal intervention once the case is set up
• it is easy to tolerate complex, changing geometries
• makes it trivial to perform parametric studies

In short, snappyHexMesh trades mesh quality for productivity.

Why does this trade-off matter?

CFD applications in the context of industry is very rarely about running one perfect case.

More often than not, you need to deal with:

• geometry iterations
• design sweeps
• evolving requirements
• tight deadlines

In this context, if it takes days or weeks for you to rebuild your mesh, or if you have a workflow that is too fragile that it breaks when there are geometry changes, you are in trouble.

snappyHexMesh, or similar meshers with an easy interface that gives you acceptable meshes allow teams to:

• regenerate meshes quickly without significant downtime
• embed meshing into automated/productionizied workflows

These are often more valuable than obtaining the best mesh possible for the case.

But snappyHexMesh generates objectively worse meshes?

To quote Robin Knowles from CFD Engine:

snappyHexMesh Rule #1 – Don’t Zoom In 🙈

I think it is a common misconception that snappyHexMesh is bad and structured meshes are good.

In reality, while a perfect mesh that rarely gets updated would provide stale insight, while a slightly imperfect mesh that adapts quickly to your case and geometry quickly produces trends.

In many industrial applications, relative accuracy and consistency matters much more than absolute precision.

Boundary layers and wall-modeling

There is no need to sugarcoat it: snappyHexMesh generates poor boundary layers.

• it does not guarantee high-quality layers
• it struggles near sharp edges and tight gaps
• it requires careful inspection

Therefore, for cases where wall shear stress is the primary focus or detailed near-wall resolution is essential, structured meshes still have a clear advantage.

Having said that, for many combustion and engine applications, bulk flow is more important (not that I think that near-wall is unimportant, for instance for wall heat losses), making this limitation acceptable as long as it is understood.

TLDR, which is better?

I think the more useful question is:

What problem am I trying to solve, and how often does the geometry change?

• If you do not anticipate changes in geometry or anticipate sweeps in design space: GridPro is the absolute winner.
• If your geometry evolves and iteration speed is important: snappyHexMesh is better.

In practive many teams in industry use both, in addition to other meshing solutions, depending on the objectives of the project they are working on.

Final thoughts and some references

snappyHexMesh is not a bad mesher, it is a deliberate compromise for industrial applications.

I think understanding this compromise and using this tool when necessary is far more useful than chasing after the mesh perfection.

Some further reading on snappyHexMesh I can recommend:

• OpenFOAM User Guide on snappyHexMesh, an absolute necessary read that explains the fundamentals

• A Master’s thesis from Mr. Bishal Shrestha that I advised, where we investigated the effect of mesh in accuracy in performance in TCC-III engine

• A blog article from Robin Knowles from CFD Engine that I referenced in the text, which echoes similar sentiments towards snappyHexMesh with this post.

• A blog article from Thaw Tar from CFD Monkey, giving some tips and tricks on snappyHexMesh applications

Thanks for reading, — Bulut