# Fixing Divergence Issues

## Contents

# 8.4. Fixing Divergence Issues#

In the event of a diverged cases, this section provides recommendations that may help to address the issue.

## 8.4.1. General Recommendations#

When a case status indicates **diverged**, which means either the Navier-Stokes solver or turbulence solver has diverged, it is necessary to identify the source of **divergence**.

Check the arguments of the case configuration file and make sure values for the flow conditions and boundary conditions are properly assigned. The divergence issue could be due to an unintended input, for instance, assigning value of

`muRef`

to`Reynolds`

by accident.Verify that there are no obvious problems with the mesh. For example, confirm that there are no negative volume cells and that boundary conditions are correctly assigned. Any obvious mistake that can be detected by a quick a review and is related to the mesh can potentially cause divergence.

Find the location of

**divergence**. In the actions section in front of each case, by selecting the download button, logs/flow360_case.user.log file can be downloaded.

### 8.4.1.1. Investigating the Location of Divergence#

At the end of the “flow360_case.user.log” file, the user can find the error message for a diverged case: :code`(ERROR 3000) Solver is diverged`. A few lines above this message, users can see which solver is diverged: Navier-Stokes solver or turbulence solver.

When the Navier-Stokes solver diverges for a case, in the lines preceding this message, the minimum values for \(density\) (i.e., `min rho`

in the user log) and \(pressure\) (i.e., `min p`

in the user log), and maximum value for \(velocity\) (i.e., `max Umag`

in the user log) are written.
At the end of each line, grid coordinates are printed following `xyz=`

. The coordinates associated with nonphysical values, negative `min rho`

for example, indicate the location of divergence. Similarly, when the turbulence solver diverges, grid coordinates for the maximum residual of the turbulence model can be taken.
For example, user-log message for a diverged case is shown below.

The next step is to check the mesh around the grid coordinates taken from the flow360_case.user.log file and make sure there is no obvious problem around those coordinates.
Often an abrupt change in the area ratio or aspect ratio can cause **divergence**. It is recommended to maintain a smooth transition between small and large cells, specifically where 3D flow in the domain could be abruptly changing.
Please refer to best practices for building the mesh.

It is also possible to find the location of min/max values on the WebUI. In the **MinMax** tab, \(min\_rho\), \(min\_p\) and \(max\_umag\) variations are shown with respect to pseudo steps.
For example, by clicking on the \(min\_rho\) plot, a table appears that shows the value and location of the selected point. In the case of **divergence**, clicking on the last pseudo step plotted will present the location of divergence.

## 8.4.2. Steady Simulations#

When running a steady simulation, **divergence** may occur because of improper tuning of the CFL value. The CFL number defines the rate by which the information is traveling across a computational grid. The greater the value of CFL, the faster convergence can be achieved. However, the allowable CFL number depends on the characteristic size of the mesh cell.
A CFL number that is too large for the mesh and flow can cause the linear solver to diverge. When a steady case is diverging and the cause of **divergence** is none of the above-mentioned issues in general recommendations, please follow the instructions below.

### 8.4.2.1. Checking the user log#

The first step is checking the flow360_case.user.log file and making sure that the simulation runs for at least a few pseudo-steps before it diverges. If a simulation immediately diverges without any iterations, please review guidance in general recommendations.
Often a very small initial height in the boundary layer could require the initial CFL value to be less than 1 in order to be able to start a simulation and to avoid immediate **divergence**. In that case, ramping the CFL value can be used to avoid lengthy iterations to achieve proper residual drop for a steady simulation.

### 8.4.2.2. Reducing the initial value of CFL number#

If a simulation starts and runs for some pseudo-steps and then it diverges, as an initial test, users can reduce the initial value of the CFL number to a small value and see if this affects the iteration at which the **divergence** happens.
If the iteration at which the **divergence** happened changes by decreasing the initial value of the CFL number, this means that the CFL number for this mesh and case configuration must be tuned.
Tuning the initial CFL number for a fine mesh can be time consuming. It is recommended to decrease the initial CFL value substantially to help ensure that the early divergence is avoided. Testing initial CFL reductions with a coarse mesh can help as well.

### 8.4.2.3. Increasing the ramp step#

If the simulation diverges after the final CFL number is achieved, then the ramping step can be increased further to delay the iteration by which the final value of the CFL number is achieved to avoid **divergence**.

### 8.4.2.4. Decreasing the final value of CFL number#

If the simulation starts and runs for some pseudo-steps and diverges when the value of the CFL number is being increased toward the end of the ramping step, and increasing the ramping steps doesn’t help to avoid the **divergence**, the final value of the CFL number can be decreased to avoid **divergence**.

### 8.4.2.5. Improving convergence when residuals are stalling#

If the above CFL recommendations have been addressed and the residuals remain “stalled” (i.e., no longer reducing), locally increasing the mesh resolution in areas of high gradients can help to obtain better convergence. Another possible option in this instance is to run an unsteady simulation until a stabilized solution is achieved with improved convergence.

### 8.4.2.6. Avoiding divergence through the use of `adaptive`

CFL#

Instead of using the `ramp`

approach, where the `initial`

, `final`

and `rampSteps`

need to carefully be chosen to avoid divergence, the user can switch to the `adaptive`

algorithm, which automatically adjust the CFL number based on the linear residuals (see more in the adaptive CFL knowledge base). To demonstrate through an example, we use the ONERA quick-start example with an increase in alpha to 10 degrees, which makes it a more complex case that is more susceptible to divergence than the baseline case. For the `ramp`

simulation we used a ramping of CFL from 5 to 200 over 100 ramp steps, which diverges after 110 pseudo steps. On the other-hand the `adaptive`

CFL with default settings, manages to converge this simulation, with the residuals convergence and CFL values during the simulation shown in Figures Fig. 8.4.3-Fig. 8.4.6. It must also be noted that the `adaptive`

CFL value at the end of the simulation is approx. 240 which is above the final value for the `ramp`

simulation.

## 8.4.3. Unsteady Simulations#

When running an unsteady simulation, and the case is diverged, please first check the general recommendations and make sure that none of the issues referred is the reason for **divergence**.

It is recommended to have residuals drop at least two orders of magnitude within each physical step. An example of unsteady residuals are shown in the below figure.

### 8.4.3.1. Starting from an initial solution#

Initializing an unsteady simulation with a well-developed flow field is recommended. A steady-state simulation or a first-order (i.e., `orderOfAccuracy: 1`

) unsteady simulation with few physical steps are often effective to initialize the flow field. The intended second-order (i.e., `orderOfAccuracy: 2`

) unsteady simulation can be forked from the initialization case.
More information about first and second order simulations can be found in Navier-Stokes solver.

### 8.4.3.2. Checking the user log#

The next step is to check the flow360_case.user.log file. When a case is running for at least some physical steps and then diverges, reducing the initial value for the CFL number can help to avoid **divergence**.
Often it happens that for an unsteady simulation with a mesh that has a very small initial height in the boundary layer, an initial CFL value of less than 1 can help to avoid **divergence**. In that case, ramping the CFL value can be used to avoid lengthy iterations to achieve at least two order of magnitude residual drop in a physical step.

### 8.4.3.3. Reducing the time-step size#

The time-step size can also be reduced to help address the **divergence** issue.
The time-step size can be set properly for an unsteady simulation based on the minimum edge-length in the mesh and the CFL number. It also can be set based on the Strouhal number and how a physical phenomena is changing with time. Specifying a time-step size that relates to 100-200 steps per flow phenomena (e.g., vortex shedding frequency) is often appropriate.

### 8.4.3.4. Reducing the final value of CFL number#

If an unsteady simulation starts, and the time-step size is properly chosen, the final value of the CFL number can be reduced to address the **divergence** issue.

### 8.4.3.5. Increasing the ramp step#

If an unsteady simulation starts, the time-step size is properly chosen, and the final value of the CFL number doesn’t cause divergence, the ramp steps and corresponding number of pseudo-steps can be increased to address the **divergence** issue.

## 8.4.4. Final Considerations#

### 8.4.4.1. Checking the maximum residual#

For both unsteady and steady simulations, in the event that the above mentioned recommendations did not help to address the divergence, analyzing the residuals in the flow field may be required. Residual data can be included in volumetric solution outputs and postprocessed. See entries starting with `residual`

in the Solver Configuration Output section.

### 8.4.4.2. Sudden divergence without proper cause#

If none of the above issues could address the divergence issue please contact the Flexcompute support team (support@flexcompute.com) and let us help you with your simulation.