This page will provide some suggestions on input parameters to change if the flow solver fails. If at some point you struggle to get the flow solver to converge, but find a solution, please contact the group administrator so that these tips can be updated for future students.

Step 1: Determine when the flow solver failed.

• The flow solver can fail either due to the linear solver or the nonlinear solver in either the approximate or inexact phase. Knowing which combination it fails in is important to ensure you only change relevant parameters and not waste valuable compute resources (which cost significant time, money, and CO2!).  As a general rule,

  • Success of the linear solver (GMRES) can be determined by looking at the convergence of |res|/|res0| in each outer (nonlinear) iteration in results.solv, which is the normalized residual of the linear problem Ax=b at each outer iteration (time step). If this residual is not dropping, or is taking too long to converge, you likely have an issue with the linear solver.

  • Success of the nonlinear solver (approximate or inexact Newton) can be determined by looking at the nonlinear residual drop, i.e. the |Res| drop in results.solv, or res in results.his.

  • Remember that unsteady problems should not have any significant drop in the nonlinear residual

• At the bottom of this page is a relevant section of Todd Chicholm's thesis that provides more details on distinguishing between these two phases, and some appropriate debugging ideas.

• Nonlinear solver fails in the approximate phase: 

  1. If the solver seems to be limboing without reducing the residual, a first thing to try could be to use a smaller time step/more gradual time step ramp-up. This will slow down the convergence, but might just help the solver get unstuck. You may also benefit from solving the linear solves to a higher accuracy.

  2. You may benefit from increasing the dissipation, either by switching from matrix (diablo%idmodel=2 or 4) to scalar dissipation (diablo%idmodel=1 or 3) or by increasing the coefficients of the first and third order dissipation diablo%dis2 and diablo%dis4. Refer to Zingg's second textbook, 4.4.3 for details. A change between "regular" (diablo%idmodel=1 and 2) and SBP dissipation (diablo%idmodel=3 and 4) may or may not also help.

  3. On the other hand, for the cases where the algorithm is converging and you want to make it converge faster, you could loosen the linear solver tolerance or lower the fill level.

  4. Potentially the pressure switch (again refer to the second CFD textbook, section 4.4.3) is having an impact, so you can try setting diablo%p_switch = .false., but you should be careful here that the final result is still reliable. There may be large numerical errors since the lower order dissipation is effectively switched on everywhere, unless diablo%dis2=0. You can see how this pressure switch is implemented and dissipation coefficients are calculated in the subroutines calcSmoothUpsilon and calcCoef24 in EiulerRHS_Mod.f90.

  5. You may want to consider warm-starting your runs, i.e. first perform a flow solve with excessive dissipation, then restart from this converged flow solution using diablo%restart = .true. and diablo%use_frstrm = .false., progressively decreasing the amount of dissipation until you achieve something realistic.

• Nonlinear solver fails in the inexact phase: 

1. Your initial iterate coming from the approximate phase may be too far away - i.e. your initial "guess" is too far away for Newton's method to converge. In this case try reducing the drop tolerance.

• Linear solver fails: 

1. Try increasing the Krylov subspace or fill level for the appropriate phase.

2. Use a different preconditioner?

3. See Tom Chisholm's thesis below for a more thourough debugging process.