Simulations with large time steps (high CFL)
 

Hi everyone!

I have been trying to run simple 2D RANS simulations over an incompressible airfoil, from 0deg to 15deg. I thing I need some help!

Everything works just fine when I use a steady solver. However, things do not work quite so well in time-accurate mode. They work, but the CFL constraint forces me to use a very low time step. Basically, it takes 32,000 time steps for a particle to go from leading edge to trailing edge. Slightly excessive I'd say.

If I use 5 outer correctors in pimpleFoam, the CFL remains more or less steady, around 80 (the value that I want). Still, I am afraid that sooner or later, it will keep on increasing and eventually explode...

Is there any way to run such simulations with larger time-steps, while maintaining spatial and time accuracy? Some colleagues use OverFlow and Fun3D and they have no problem with that.

Thank you very much for your help!

Joachim

no one?

I can't believe there is no way to run a 2D airfoil in time accurate mode with OpenFOAM... :(

Greetings Joachim,

Have you checked OpenFOAM's tutorial "incompressible/pimpleDyMFoam/wingMotion"?

As for the "trick" to not having high CFL is to have a good mesh that doesn't have very small cells in high speed zones.

You can use the Co utility for generating the Courant Number field for your case, so that you can find where the CFL values are higher.
Another thing is to check the mesh statistics given by checkMesh, namely the minimal cell volume.

Best regards,
Bruno

Thanks wyldckat, :)

However, I do not have much choice in this case, for 2 reasons:

1. The airfoil has a blunt trailing edge. I need really fine cells to properly capture the flow there.

2. A colleague and I are running the same case on both OpenFOAM and Overflow. We are therefore using the same mesh. -> I cannot change it.

It is pretty frustrating! In Overflow and Fun3D, they don't have that issue with the CFL.

Find out what makes Overflow and Fun3D faster. What algorithms do they implement? Are all other settings the same? It wouldn't surprise me if those codes implement algorithms that outperform OpenFOAM in specific cases, and if so you can either stick to using those codes, or if you really need OpenFOAM and the improved performance, implement the algorithms into OpenFOAM.

Hey!

I would like to check the solver implementation in Overflow and Fun3D, but I can't! I am an international student, and therefore I am not allowed to see the code...that's why I am using OpenFOAM. :D

Even without access to the code you should be able to get everything you need from theory guides or white papers or such.

You should be able to find the properties of the algorithm: SIMPLE or PISO, how many correctors, local-time stepping tricks, ... ?

Actually, I am pretty confused right now. Is the PISO algorithm implemented in OpenFOAM really a PISO algorithm? The solver is supposed to be coupled and not segregated. However, it clearly seems to solve first the momentum equations over the entire domain, and then apply the pressure equation.

If you google "Pressure Velocity Coupling - Hochschule Luzern", you'll find a powerpoint presentation (OF workshop 2010) where two people apparently implemented a "real" PISO algorithm. They were able to run simulations with Courant numbers above 500 without any problem. That is pretty strange. That was three years ago, but the algorithm is still not included in the official version of OF. I am going to contact them directly to see if there was anything wrong with their solver.

Else, it seems that a vector coupled solver was added in the release OF 2.2.0 (http://www.openfoam.org/version2.2.0/matrix-solvers.php). However, I tried to run the cavity case given as an example, while refining the mesh (-> increasing the CFL), and the simulation still diverged for CFL > 1.

Be careful when you see presentations like this...

Most of the time, people make those beautiful tries on OF 1.6 ext which is not an official OpenFoam release ! The "extend" project is independent from OpenFoam (2.2 now). The extend version implement whatever they want and even sometimes code that is under copyrights (see the problem OF Ext vs Ansys few months ago). They can do it because it is an opensource project without any "leader" to blame (or to judge).

What you saw in the power point is really attractive but it requires lots of code that was not natively in OF. It requires extra work, extra maintenance and extra files. Moreover, as far as I remember, the way OF works doesn't allow a straight forward coupled algorithm.


To be clear: PISO, SIMPLE and COUPLED are 3 different algorithms. Sometimes you can also see SIMPLEC which is an "consistent" version of SIMPLE.
Basically, SIMPLE solve the equation one by one and use a corrector. PISO is an "improvement" of SIMPLE since it adds a second corrector stage that helps coupling pressure and velocity. COUPLED is another algorithm where pressure and velocity are solved at the same time.

PISO and SIMPLE solves two systems (pressure and velocity) while COUPLED solve a unique system. The biggest problem is that COUPLED uses much more memory and it can be in some cases as slow as PISO if you have a very turbulent flow.

Oh thank you, I did not know that.

But basically, it means that right now, OpenFOAM does not have any coupled solver and therefore cannot run simulations with arbitrarily large time steps?

Yes, that's right ;)

And be careful, some "researchers" would call you crazy if you use a coupled solver with low speed. Indeed, the coupled algorithm was originally designed for high mach problems (Mach > 0.4). It turns out that the algorithm is actually quite efficient for other purposes (low turbulent flow) but people often want to stick to the original use.

But then, is it actually possible to run subsonic external aerodynamics simulations in OpenFOAM?

I mean, if you have a mesh with roughly y+ = 1 and a free-stream velocity corresponding to M = 0.2 for example. You will immediately get very high CFL, if you use time steps that would be short enough to capture all the unsteadyness of the flow. Still, the calculation will blow up...

Is there any way around this? Is the compressible solver more stable than its incompressible counterpart?

Thanks!

Haha, that is a main problem of CFD...

First, you can improve your mesh. On airfoils, you can have area of high velocity but low pressure gradient. Therefore you don't need small cells in this area (wide rectangles should be good, aspect ratio of 40). You can also try to reduce as much as possible the number of cell in your domain.

Second, you can try to play with the number of corrector loops.

Third, you can use some implicit algorithms that allow larger time steps. But be very careful ! An implicit solver with large dt that works (no crash) doesn't mean that your solution is right... In some cases, the solver doesn't crash but still give you inaccurate solution.

Fourth, you can use a steady state solution to initialize your problem.

Fifth, no matter what, you cannot use time steps larger that the frequency of your flow. You can refer to the "Strouhal" number to get an idea of the vortex frequency and then you apply the Nyquist–Shannon sampling theorem.

Actually, this is my big problem! If I want to have a CFL of 1, the time steps are so small that it takes 32,000 iterations for a particle to go from leading edge to trailing edge. I really need this accuracy in time, but it seems that I don't really have the choice.

I'll get rid of my blunt trailing edge and coarsen the grid then!
Thank you for the recommendations.

What is your number of cell ? What is you current time step ?

If you want to get accuracy, you don't really have choice. Any drastic improvement will be made at a cost...

Fredo and Joachim, I have a question about what you were discussing here.
If this is true, why can Fluent handle arbitrarily large time steps with their "transient simple", which is pretty much the same as pimpleFoam? This is a segregated solver as well. I can run really large time steps (and thus co numbers) in Fluent and with the very same mesh I need to have like 10-20 times smaller time steps in pimpleFoam.

Transient SIMPLE is not like Pimple (Pimple is still basically PISO). The trade-off between SIMPLE and PISO is that you need to apply under-relaxation (yet another tuneable parameter!) and a lot more iterations per time step for convergence using SIMPLE to get the large time steps.

I don't really get what you say, sorry. I run Fluent "transient SIMPLE" with 15 Iterations per time step and it is stable. pimpleFoam with 15 it/dt isn't. Both use the same under-relaxation (pressure 0.3, momentum 0.7 and turbulence 0.8) and I tryed to set Openfoam numerics as "Fluentish" as possible.
1) I know PISO isn't SIMPLE, but the two solvers (Fluent and OpenFoam) in my case both use inner iterations with under-relaxation each time step to account for coupling of pressure and velocity.
2) How does the argument hold, that the reason is the segregated solver if both programms use them?

Just because you apply underrelaxation and more iterations does not make your PISO loop (which pimple still is) SIMPLE. You are still comparing two different algorithms which both have their pros and cons.

I couldn't understand the point you were trying to make in 2).

My original question was about a discussion in this thread where fredo490 said that OpenFOAM doesn't have a coupled solver and thus can't handle arbitrarily large time steps. But Fluent can handle these time steps without using a coupled solver, so my question was why. Also why isn't there a solver like that in OpenFoam, or is there any way I can tune pimpleFoam for larger time steps?

Also, what I am wondering: PISO, Simple, Simplec, Simpler... they are all more or less the same as I understand them. Just different approximations or some extra loops. But how can that lead to such different behaviour?

Hello,

Just a bad trick, if you solution don't change to much over time

- try a "compressible" solver instead of incompressible,, even if you don't have much compressible effect => may run faster
- and try with Local Time Stepping (LTS), ex: rhoLTSPimpleFoam instead of pimpleFoam.

in fvSolution
- use "nOuterCorrectors 10" <- 10 or more
with residualControl to the wanted tolerance.

... And always check if the solution is correct ...

But you still can't get as high dT as in Fluent.

regards,
olivier

Phillip, read Jasak's comments on transient SIMPLE here:
http://www.cfd-online.com/OpenFOAM_D...es/1/1807.html

Then have a look at:
http://openfoamwiki.net/index.php/Ma...ransientSimple

Also read more theory on PISO and SIMPLE. It is not as simple as just adding or removing extra loops.

Of course, I did. I read in Ferziger, Peric:
"Still another method of this general type is derived by neglecting ui' in the first correction step as in the SIMPLE method but following... it is known as the PISO algorithm"
And in Versteeg, Malalasekera:
"PISO involves one predictor step and two corrector steps and may be seen as an extension of SIMPLE, with a further corrector step to enhance it."

That's why I was stating that all these methods base on more or less the same principle. I am curious why you think they are essentially different (or not "just you", but why they actually are).

Yes, I agree the methods are related, but I don't think that's a strong argument to assume very similar numerical behavior (side-note: similarly, you could argue first and second order time discretization should have the same properties because they only differ by a factor theta).

PISO involves explicit correction steps, which is why your time step ends up being limited. These explicit correction steps are not part of the SIMPLE method.

Another side note - the differences between PISO and SIMPLE grow when looking at compressible flows, as now also the density is updated in a different manner. Issa brings this up in his 1986 paper on the development of PISO.

I still got more questions, I really appreciate your help here!
I am wondering why I get this behaviour in pimpleFoam:
Attachment 34145
You can see that after 24 iterations pimple residuals jump at the last iteration to pretty much the initial value. Why? I thought this must be from under relaxation, which isn't done in the last iteration. But I then set relaxation factors to
So there is nearly no under relaxation. Why are the iterations 24 and 25 so different? Do you think it will still come from this? And why is it so high?
This is the log output:

I don't really use the pimple solver, so I can only guess. To me it looks like while your solution seems to be ok with the relaxation, the final result in iteration 24 is still not a great initial guess for a solution without underrelaxation. Thus in iteration 25, where no relaxation is applied, things break down. Hope someone with more experience with pimple chimes in too.

Would it be possible to use OF3.1-ext for pimpleDyMFoam to achieve higher CFL? That is, an overal implicit approach.
I am trying to simulate a wind turbine with 3 blades. The mesh just at trailing edge is really small so the time step should be really low to match a CFL=1.
For perfom 1 iteration per 1 degree of rotation, the max CFL is around 700 while the average is around 0.007.
For CFL=1, the simulation time maybe could last 2 months...

transientSimpleDyMFoam
 

What about transientSimpleDyMFoam solver?
What are the diferences wrt pimpleDyMFoam?

Greetings be_inspired,

For some details about "transientSimpleFoam": http://openfoamwiki.net/index.php/Ma...ransientSimple

As for using a CFL higher than 0.5 or 1:

• Why don't you simply use a steady-state solver?
• Or use the CoBlended feature that was introduced in OpenFOAM 2.2: http://www.openfoam.org/version2.2.0/numerics.php

Best regards,
Bruno