[xisluke]

Hi guys! I have two different questions regarding how Fluents deals with PISO and SIMPLE algorithms:

1 - It seems that Fluent allows the user to set up a pressure-based transient problem implementing the PISO algorithm and contemporary defining under-relaxation factors... Does it make sense? I was pretty convinced that under-relaxation are related to SIMPLE or PIMPLE schemes...

2 - I saw also that for Fluent it's possible to perform transient analysis with SIMPLE algorithm, another time, does it make any sense? I always considered SIMPLE for steady state problems...

Could you guys correct me if I am wrong? I'm trying to understand if my CFD knowledge needs some improvements or simply Fluent allows the user to set up also non feasible settings ahah! Thank you!

[LuckyTran]

SIMPLE and PISO can both be used for steady state and both be used for transient problems. SIMPLE and PISO are both part of the same family of predictor-corrector methods. The difference is that PISO does one extra pressure correction that is absent in SIMPLE. And then there is PIMPLE, which is a bunch of SIMPLE steps followed by one final PISO step. And just like SIMPLE/PISO, PIMPLE can also be used for steady state of transient problems.

For steady cases, it is expected that you won't converge in 1 iteration. That's why it is preferred to go the SIMPLE way and use low urf's. You can still use PISO but you will need to crank down the urf way below 1 or it will likely be unstable. No one really tries to use PISO for steady problems because the extra pressure correction step is wasted (because it would have been taken care of anyway by the next iteration). You can think of it vaguely as: 1 step of PISO costs 1.5 steps of SIMPLE. I can quickly do 2 SIMPLE steps much faster than I can do 2 PISO steps so that extra computation time had better be worth it! As it turns out in most cases, it's not worth!

For transient cases.... If your case is stable enough (i.e. you use really really small time-steps) you can converge in 1 iteration without any urf and here it would make sense to go PISO. But if you can't make it stable (i.e. you have to use relatively large time-steps) then you need to use urf<1 and you now have a choice of whether you want to do SIMPLE/PISO/PIMPLE and most people will choose SIMPLE/PIMPLE when this happens. So you will find instances of people using either SIMPLE or PISO in transient cases depending on their time-step size.

There are actually some very niche cases where you could use PISO with a urf=0.9 or something, do 2 sweeps, and have it be faster than doing 3 SIMPLE steps. Anyway, as far as implementation goes... because PISO and SIMPLE are algorithmically so similar, if you code PISO with URF's, then you have already done the coding for SIMPLE with urf's.

[xisluke]

Thank you LuckyTran! I think I'll return on some books to refresh the maths, but I think I've catched the point Another question, considering PISO for transient pressure-based cases, it's necessary to deal with low time steps, so also low courant number (I set it always <1); in OpenFOAM, within the controlDict it is possible to specify what courant number to be maintained during the solution process, but it seems that within the Fluent control panel it is only possible to set the urfs, not the courant number... Is there any other place to set it? Big thanks!

[LuckyTran]

That feature to modify the time-step size using Courant number is not in Fluent, afaik. You would need to do some nifty scripting and do the user-defined time-step UDF or get one from a friend (google is your friend).

Fluent does have adaptive time-stepping which modifies the time-step size based on the local ratio of truncation error to discretization error. This is actually the proper theoretical way to do adaptive time-stepping but if all you care about is maintaining a global courant number, it's overkill.

P.S. you sound convinced but going back to SIMPLE/PISO: If you go to the PISO settings and turn some of the 1's in the skewness and neighbor correction to 0's, PISO will turn into SIMPLE (but also remember to change the urf!). You can also do this in OpenFOAM by changing nNonOrthogonalCorrectors and nCorrectors in fvSolutions. If you are really curious, you can also think about what happens when you set these #'s to values greater than 1... No one does this because it's not optimal, but it is allowed algorithmically.

[xisluke]

Another time, thank you! I'll try to play a bit with different configurations and verify the outcomes!