Appendix: Solving the Pressure-Correction Equation

In the iterative solver stream, the most CPU intensive step in the solution algorithm is the solution of the pressure-correction equation. Following a successful run of the code, one can examine the debug files in /debug under the directory from which the simulation was initiated to see to top ten most expensive rules in the computation. For a single process run, the debug file is simply called debug. For multi-process runs, the debug files are named debug.*, where the wildcard represents the process number. For a typical run, especially multi-process runs, it is not uncommon to observe the pressure correction solution using as much as 50% to 75% of the entire simulation CPU time. While such usage may be justified for certain simulations, quite often one can reduce the computational expense of solving the pressure correction equation without incurring any detrimental effects on convergence within the time step. Under optimal conditions with the right selection of solver parameters, one may be able to reduce the expense of solving the pressure-correction equation to no more than 25% to 30% of the total CPU time, which can result in a substantial reduction is simulation turn-around time compared to using default solver parameters which are selected for robustness purposes.

In Stream, the pressure-correction equation is a highly approximate equation whose sole purpose is to nudge the flow solution back towards continuity satisfaction. Due to the approximate nature of the equation, it is often simply not worth over-solving the equation because the additional information may not prove to be of any value. In fact, over solution of the pressure-correction equation in the initial time steps of a simulation (when one has a bad initial condition) is a common cause of solution divergence, especially when using SIMPLE (as opposed to SIMPLEC). Thus, for several reasons, one should attempt to find the optimal balance where the pressure-correction equation is being solved “enough”. To find this optimal point, one can use a series of sample runs on either the actual problem or a similar problem and vary the level of solution of the pressure-correction equation. Starting from the default solution parameters, if one reduces the level of solution of the pressure-correction equation and sees no detrimental effect on the level of convergence of the system of equations within the time step, then the new solution parameters are an improvement. One can repeat this process until it is evident that the convergence of the system of equations within the time step is being affected in a negative manner by the reduced work in the pressure-correction equation. At this point, one would have to increase the number of iterations to make up for the loss of convergence to offset the lack of convergence due to the under-solution of pressure-correction. This primary point is that there is a general trade-off between a larger number of cheap iterations and a smaller number of expensive iterations when using Stream. With experience, the optimal location in this trade-off will become evident.

Time-Step and Relaxation-Factor Interaction

A non-intuitive behavior can occur when using very small physical time steps: reducing equation relaxation factors can make a case less stable. In this regime, increasing one or more relaxation factors can sometimes improve stability.

The reason is tied to how strongly pressure correction couples pressure and velocity. In the correction formulas, this coupling depends on both the relaxation factors and temporal-to-spatial coefficient ratios. These ratios scale approximately with \(1/\Delta t\), so they grow as the time step becomes small. For very small \(\Delta t\), some effective coupling terms can become weak, especially when relaxation factors are also small. The net result can be under-correction of continuity and degraded nonlinear stability.

This behavior is not necessarily a coding error; it is a known characteristic of approximate pressure-correction methods. For this reason, decreasing \(\Delta t\) usually requires re-tuning solver controls, rather than only reusing settings that were stable at a larger time step.

Recommended practice when reducing time step:

• Retune momentumEquationOptions(relaxationFactor) and pressureCorrectionEquationOptions(relaxationFactor) together.

• If instability appears after reducing \(\Delta t\), try increasing one or both relaxation factors before reducing them further.

• Use pressureBasedMethod: SIMPLEC for better robustness in many transient runs.

• Use timeStepRamp to transition gradually to small time steps.

• Track residual behavior (especially pressure-correction and momentum) while tuning.