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.