PIMPLE – the value of the final underrelaxation factor
Dear all,
There has been discussion about the value of the underrelaxation 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 lastiteration UF would be marked with pFinal, UFinal, kFinal. I have seen an opinion that the last iteration must not be underrelaxed due to “time consistency”. Even the default OF value for the lastiteration 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: Code:
PIMPLE: iteration 20 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 35 iterations is then needed to achieve convergence: Code:
PIMPLE: iteration 2 I ran the same case in Fluent, with basically the same settings. Underrelaxation 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 lastiteration 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 abovedescribed 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 reappearing 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 underrelaxation 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 steadystate 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, OpenFOAM4.x. 
Quote:
Maybe increasing your nOuterCorrectors parameter in fvSolution helps. 
All times are GMT 4. The time now is 02:36. 