What can you do to ensure your computational fluid dynamics (CFD) solutions converge?  Everyone who runs CFD codes, from novice to expert, needs to know the answer to this question. NAFEMS, an independent, international authority on the use of computer modeling and simulation methods, maintains an online document called General Guidelines for Good Convergence in Computational Fluid Dynamics.

I was hoping for something insightful but these guidelines fell short.  There are only so many times you can tell the user to Read the Fine Manual.

Their guidelines are divided into 10 sections that I’ve tried to summarize below.

What Is Convergence? Generally speaking, convergence is the achievement of a limiting behavior in the solution of the equations and is typically represented by the diminishing residuals of the numerical solution.  It’s important to keep in mind that a converged solution is not necessarily an accurate one.

Quite another thing is what we call “budgetary convergence,” which means your solution is converged when you can’t afford any more computer time.  I’ve reached that level of convergence many times.

What Convergence Criteria Should be Used? The authors admit that this topic is too broad to be covered by general guidelines and that you should at least use several measures of convergence that are important to what you’re trying to compute.

Some people try to reduce the residual by six orders of magnitude or they watch the lift coefficient (if that’s an important output) to see if it reaches asymptotic behavior. This is complicated, however, by the fact that fluid flows tend to be oscillatory or even unstable.

Problem Definition. The authors cite improper problem setup as a main source of difficulties in a CFD solution.  Proper setup goes beyond simply correctly entering data for the CFD solver and includes understanding the physics, the potential for transient behavior, and accurate physical models.

What can be learned from the fact that the main source of difficulties with a CFD solution is setting up the input deck for the solver? Doesn’t that seem like something you shouldn’t have to worry about?  The authors use bold print to emphasize that you should RTFM for your CFD code.

Geometry. When it comes to geometry, the authors cite two things to be aware of.  First, are your outer boundaries far enough away?  Second, does the geometry contain unnecessary details that would make convergence a problem?

Coincidentally, the issue of outer boundaries arose just the other day in a discussion on CFD Online’s forums, which are a good source of general help.  As for the latter, the topic of unnecessary geometric details goes beyond the scope of general guidelines.  In fact, defeaturing, shrink wrapping, and other technologies for dealing with geometric complexity are huge areas of research unto themselves.

Boundary Conditions. It seems to me that BCs would fall into the problem setup category, but the authors have called them out separately. It’s true – I’ve often seen CFD solutions messed up because the boundary conditions weren’t applied correctly. However, it doesn’t always show up as a convergence issue – mostly the converged answer is wrong. BCs also cross over into the geometry category if the outer boundaries are too close and they start generating reflections.

Mesh Issues. I was hoping for a meaty discussion of the mesh that I could really sink my teeth into, but only got three bullet points. The first bullet was about mesh quality issues. Yes, indeed, if you have a bad mesh cell where something good is happening (e.g. the boundary layer), all bets are off for accuracy or convergence. However, that same bad cell could be way out in the farfield and have virtually no effect whatsoever. Metrics cited here are “mesh density, grading, orthogonality, smoothness, skewness, and cell aspect ratio.”

I’ll add that the effects of mesh quality on solution accuracy (and convergence) are too broad for general guidelines. AIAA’s Meshing, Visualization, and Computational Environments technical committee is researching this.  As one member of that TC said, “we know embarrassingly little about the effects of the mesh on solution accuracy.”

If you notice large local residuals in a specific region of the flowfield, the authors suggest using local mesh refinement or adaption to resolve the solution better.

Their final suggestion for the mesh is to align it with the flow to enhance convergence. This seems to pertain mostly to structured (mapped) quad and hex grids. However, keep in mind that mesh alignment by itself won’t do much good.

Initial Solutions. By creatively choosing how to start the CFD solution, you set it on the correct path to convergence. First, the authors again advise that you RTFM and make sure you’re setting the software’s defaults to the best possible starting point. Second, you can start by computing the flow using simpler physics – computing an inviscid solution before going full Navier-Stokes. And third, you can incrementally build up to the desired flow conditions by ramping up, for example, the Reynolds number.

I once worked with a mesh generator that initialized all grid points to the origin: (0,0,0) as the starting point for a PDE solution. By simply improving the initial guess with an algebraic method, the convergence and run time of the PDE solver was cut drastically. The same will hold for your CFD solution.

Computational Issues. This boils down to single versus double precision. Is this really an issue? Does anyone use single precision for CFD anymore? What’s fascinating is to work with people doing CFD for submarines. Because of the Reynolds numbers involved, their meshes have length scales that range over 6, 7, or 8 orders of magnitude in the same mesh. You can’t do this without double precision.  Heck, our software even does the graphics in double precision so you can zoom in good and close on your boundary layer grids.

Algorithmic Considerations. Buried deep within your CFD solver are various algorithms for computing the flow quantities. Techniques like limiters, upwind differencing, explicit versus implicit all have to be understood and set appropriately for what you want to compute. Yet again, the authors urge you to RTFM.

Software Support. Here the advice is pretty simple. Know your code developers, use their support desk, take a training course, and (again) RTFM (this time in bold).

I wholeheartedly agree with this recommendation. Our tech support engineers are here to remove roadblocks to your success. They want you to call. All too often people hold their questions and try to work around them when a brief phone call would solve everything and save them a lot of time.

In summary

NAFEMS is soliciting more input for their guidelines, so go online and submit your convergence tips today. There’s a link on the article’s site (see above).

Oh, and don’t forget – Read The Manual.