An intern joined our team recently. Fresh out of college, he was tasked with finding best practices for a particularly complex nozzle application. The internship was only to last a few months, but our new colleague was keen on showing the "real" world what he could do. With his new CFD toolset, he set-up the complete analysis with a full-blown-reacting-flow-on-the-real-geometry case - on day three... On day four, he was looking nervously at the screen wondering why his residuals continued to climb and the case did not converge. What had he forgotten to do? Where should he start looking for issues in his set up of the engineering problem? In the mesh? In the geometry? Boundary conditions? So of course we had to help debug his case!

Rather than starting the troubleshooting from scratch, we asked the intern to check what Steve had to say. “Who’s Steve” was the expected answer – "the Steve Portal!" we cried in return. Within a moment of logging in to Steve and searching the knowledge base, the intern had found the following article: “**How to debug cases with very high levels of difficulty or complexity**” – it was clearly written with our new colleague in mind! The intern successfully completed his analysis far quicker than we expected and so we have given him even more interesting work to complete!!! Steve has become his new best friend helping him to converge difficult cases and providing some expert CFD advice along the way.

Indeed, we can now see some nice converging 2D STAR-CCM+ cases on our intern’s screen! Some CFD common-sense at last. **Thank you Steve!**

**How to Debug Cases with Very High Levels of Difficulty or Complexity**

There are times where a complex case becomes difficult to run. Perhaps it has some advanced physics and perhaps it has a complex geometry as well. Divergence or some other problem persists preventing the case from running. Assuming you have checked the obvious things first (URFs, incorrect boundary conditions, mesh quality metrics) there are a few things that you can do to tackle some of the most difficult cases.

**All Divergence or Floating Point Exceptions are not the Same**Does the problem happen immediately or very close to the beginning of your run? Or is it happening later on? One of the overlooked aspects of mesh problems is the “disconnected subregion” problem. That is, a few floating or disconnected cells that can cause problems. These cells can still be of high quality, so just looking for poor cells is not enough. While there is a disconnected cell check within the “remove invalid cells” checker, doing a preview on a given region using the “split non-contiguous” option can sometimes show the problems. What you are looking for is the presence of individual or small clumps of cells with no connectivity to the rest of the model. Without that connectivity, the code cannot associate those cells as communicating with boundaries or obtaining a correct reference pressure for them, and problems can arise quickly, sometimes at the first iteration.

Likewise another cause of early problems is the default setup (or sometimes flat out ignoring) initial conditions. An inlet pressure boundary of 1000 atm with an initial condition of 1 atm (left as default most likely) can cause solver problems, even as soon as the first iteration.

**Examine the Physics Setup**Many sim files are set up using

**Ramping a Quantity**This is one of the most useful things to do with difficult cases. Time-steps, rotational speeds, boundary conditions can be ramped. All of these items, and more, can be ramped

using field functions. Consider a case of a rocket nozzle where the pressure difference (upstream and downstream nozzle pressures) is known, but when the pressure difference is applied the case diverges. When the boundaries are changed such that both inlet and outlet pressures start out as identical values, and the outlet pressure is gradually ramped down to the desired value, the case runs smoothly. This technique is especially important for supersonic cases, due to the requirement for specifying the supersonic upstream boundary pressure.

**Boundary Conditions**These can be utilized in non-conventional ways. You can specify a negative mass flow rate or velocity at an inlet to turn it into an outlet. This technique can help obtain a desired outcome or even perhaps get a decent initial condition for a run of a new case with the fully desired boundaries.

**Understand Code Methodology for Pressure Reference Locations**

If you have a model that does not have any boundary which specifies pressure, then the **pressure reference location** is applied automatically to the minimum X,Y,Z coordinate in the domain. A boundary that specified pressure can be a stagnation, free stream, or pressure boundary for instance. If this behavior is not what you want, you have the freedom to specify a pressure reference point.

**Gravity**

If gravity is on, be sure to account for variation in pressure due to the “rho*g*h” term, both for the initial conditions and any boundary conditions. Accounting for this variation resolves many difficult buoyancy driven natural convection cases.

**Simplify your Case**

You have a combustion model that is diverging? Turn off combustion and run the case to see if it still diverges then. Your ideal gas case keeps coming up with negative densities? Run constant density to see what happens. This method can help on two major fronts. The first is that it helps deduce where the problem is, perhaps what physics model could be the cause. The second is that it can even help to solve your problem. If they are restarted from a good converged constant density case instead of from scratch, many cases that diverge with variable density models actually behave.

**Check the transient time-step**

It is easy to translate the “check time-step” statement to mean “reduce time-step by order of magnitude”. In some cases, reducing the time-step does help, but in reality, a time-step size must be based in some part on what is modelled. If you are running a turbo-machinery case for instance, maybe use a time-step that equates to 1 degree of rotation. If you are running a case where the desired output is drag on a vehicle, calibrate the time-step so that it takes 100 time-steps for a particle to reach the span of the vehicle. There must be some science to selecting a time-step.

**For Transient Simulations, Converge all Time-Steps**

A commonly overlooked error is to assume that the default number of inner iterations per time-step is adequate. In reality, this value is either not sufficient or an overkill, for most problems. It is imperative to define other inner iteration convergence criteria for all transient simulations. Things like the momentum terms, continuity, and any engineering monitored quantities of note are among the items that are commonly used here.

See also STAR-CCM+ User Guide section: "Running > Troubleshooting the Solution"

___

For more helpful tips from Steve, log on to The Steve Portal.

Entry to the Steve Portal, CD-adapco's customer service center web-site, containing software downloads, knowledge base, and other useful links, is permitted to registered customers of CD-adapco. To become a CD-adapco customer, click here.