PIMPLE – the value of the final under-relaxation factor
 

Dear all,

There has been discussion about the value of the under-relaxation factors (UF) in the last iteration (OuterCorrector) of the PIMPLE algorithm. At the same time, many people have complained about high values of the pressure initial residual. As far as I understood from my test runs, these two factors are closely related.

In PIMPLE, let’s assume that you set nOuterCorrectors (number of iterations within one time step) to 20 and nCorrectors to 2. The first 19 iterations will be calculated with UF marked in relaxationFactors dictionary in fvSolution file as p, U, k etc. The last-iteration UF would be marked with pFinal, UFinal, kFinal. I have seen an opinion that the last iteration must not be under-relaxed due to “time consistency”. Even the default OF value for the last-iteration UF is 1. However, I must admit that I do not understand this point. Within the time step we gradually iterate towards the final value via 20 iterations – in other words, it is gradual approaching towards the final value within the time step. The iteration number 1 would bring us a bit closer to the final result, iteration 2 takes values from iteration 1 and brings us even closer and so on. So why having the UF equal to 1 in the last iteration would do anything with “time consistency” or whatever else?

Just to show a few examples. I have a mixing tank case. If I run with UF equal to 0.3 for p and 0.5 for k, epsilon and U, and UFFinal equal to 1 for all, I typically get the following output:

You can see that the pressure initial residual is low in the second to last iteration, 10e-4. However, in the last iteration it jumps up to 10e-1 due to the UF equal to 1. This is then transferred to the next step that starts with a high residual value and that’s why about 20 iterations are needed to achieve convergence. The initial residual value is high.

If I set final and "normal" UF the same, i.e. the p/pFinal is 0.3 and U/UFinal, k/kFinal, epsillon/epsilonFinal are 0.5, the initial residual value drops significantly in the last step. Only about 3-5 iterations is then needed to achieve convergence:

In my case, I was able to run the simulations with all UF set to 1 as well since PISO was able to handle that. And the convergence was still fast. So the main problem to me seems to have different UF values in the final and previous iterations. The results may not be damaged but you definitely need to perform many more iterations to achieve convergence.

I ran the same case in Fluent, with basically the same settings. Under-relaxation was applied as well and I can say that the residuals (or convergence behavior if you wish) I was getting were very similar to what I can get from OF in case I use the same UF factors in all iterations. So from my point of view the last-iteration UF factors equal to 1 are questionable.

I would appreciate any input on this topic.

Best,

Zbynek

A short update: if I set the relaxation factor for p/pFinal as 0.5/0.5 or 0.5/1, the convergence is good in both cases. If I set k/kFinal or epsilon/epsilonFinal to 0.7/0.7 or 0.7/1.0, the convergence is good again. However, U/UFinal seems to be the place where the culprit is hidden. It needs to have the same value for both U and UFinal. If I set it as 0.7/0.7 or 1/1, it works just fine. However, if the settings is 0.7/1 or 0.5/0.7 or anything else where U != UFinal, then the above-described problem occurs.

I do not know what exactly causes the problem since I am not a mathematician and I am not able to see deep enough in the code. However, I hope that this observation will help someone to solve the convergence issue that keeps re-appearing in the forums and maybe someone will bring up a decent explanation of the problem sooner or later.

Did you compare actual results in your tests? Ultimately that's the only thing that matters.

As akidess said, the important thing is that the results should be achieved. In a mathematic point of view the last iteration has to be 1 to be sure to go to the value we need during time. However this can lead to instability as you mentioned and even if you have 5 iterations and the residuals are very low you can go on. There should not be a need to have *Final = 1 but in the mathematic point of view we would miss some information. If you have problems with the momentum predictor, just turn it off an check it again. Sometimes the momentum predictor leads to some instability (I do not know why but you can try it too).

In some development of a college , we are forced to unset the momentum predictor. Otherwise the results are complete unphysical.

Guys,

I appreciate your input. I compared the results for both cases just by quickly looking at the contours and vectors and I would say that they are basically the same. The difference is just in the convergence behavior and therefore also in the computation speed. If one uses different values for U and UFinal, the solution is kind of "destabilized" at the end of the time step and the initial residual jumps up. The solver then needs to do more iterations in the next time step -> slower computation.

@Tobi

I tried to turn off the momentum predictor but unfortunately it did not do the trick.

Hi Zbynek,

the iteration loop with under-relaxation yields time step dependent errors, if UF are used. The reason is, that e.g. assuming a linear fall in velocity with a UF of 0.5 the velocity after 50% of the time step are calculated. The remaining error is 50%. Multiple iterations decrease this time step error, e.g. after 2 iterations the error falls to 25% and so on. (UF^No._of_Iterations).
This is important for transient flow behaviour, because then you do have a difference in velocity at each time step. If your flow behaves steady-state even transient calculations will not change the resulting flow, if you do not use UF=1 in your final step (each iteration improves your solution further). For highly alternating flow UF should be "as close to 1, as stability allows".

This is an old post, but does anybody have a good explanation?

If I set my p and pFinal to the same value, the simulation runs smoothly. However, if p is set to something like 0.7 and pFinal 1.0, the simulation diverges. Any thoughts?

I'm using a modified rhoPimpleFoam solver with added passive scalars, OpenFOAM-4.x.

I am starting to use pimpleFoam recently.
Maybe increasing your nOuterCorrectors parameter in fvSolution helps.

Hi All,

I have been wondering the same thing too. I am not even sure what I can add to the discussion, but here is my take anyway because I have stumbled across this problem recently and I am in general somewhat cranky when it comes to explanations of the "art" of running simulations. I totally appreciate them anyway though, do not get me wrong.

So, the simplified versoin of the PIMPLE algorithm is a SIMPLE algorithm for every time step. It is SORT OF (correction needed if I am wrong):

velocity_change_in_timestep = Navier_Stokes_by_SIMPLE_algorithm(U,p,k,etc.) (eqn. 1)

whereas a steady state SIMPLE algorithm would be

0 = Navier_Stokes_by_SIMPLE_algorithm(U,p,k,etc.) (eqn. 2)

Now, I agree the SIMPLE algorithm will have errors. We all agreed to that fact when we realized we could not solve our Navier-Stokes equations exactly. I also agree that the convergence is slower if the underrelaxation factors (UF) is lower and the error of the algorithm at a given SIMPLE iteration is higher compared to a UF closer to 1.0 at the same number of iterations.

Now there is another piece of information here: the iterations of the SIMPLE algorithm does not have a "timestep" meaning for a steady case, i.e. we cannot imagine the iterations of SIMPLE as an evolving flow field. Rather, that is the convergence of the solution in the predictor-corrector operation approximating the nonlinear Navier Stokes equations, i.e. the distance of the solution_vector to the exact solution of the Navier-Stokes_operator(solution_vector) = 0.

According to this, I do not see the reason why the last iteration, say iteration 20, of SIMPLE is more important than an iteration in the middle, say iteration 13, in equation 1. Every SIMPLE iteration denotes mathematical convergence, not physical evolution of the flow, hence the overall convergence of SIMPLE to the transient Navier Stokes operator should be the relevant quantity. I do not see how there is a mathematical difference between obtaining SIMPLE convergence to the Navier Stokes equations using UF=0.7 in say 20 iterations compared to UF=0.6 in 29 iterations and UF=1.0 in the 30th iteration (totally made up numbers, but you get the point).

Best Regards,

Ali

1. In my blog there is a explanation of PIMPLE and how to use it
2. In my book there is also an explanation with more information
3. Depending on your under-relaxation, you are may not be time-space consistent anymore, e.g., doing 50 outer-loops with 0.1 under-relaxation. After thinking it should be clear
4. Identifying the problem why it diverges even with high outer-loops and underrelaxation will potentially resolve your issue.
5. Numerical settings such as non-ortho correction is something to consider as well (also in the discretisation)
6. Solver settings might support your calculation