[Joachim]

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

[Joachim]

no one?

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

[wyldckat]

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

[Joachim]

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.

[akidess]

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.

[Joachim]

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.

[akidess]

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

[fredo490]

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

[Joachim]

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.

[fredo490]

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.

[Joachim]

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?

[fredo490]

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.

[Joachim]

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!

[fredo490]

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.

[Joachim]

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.

[fredo490]

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...

[RodriguezFatz]

Originally Posted by fredo490

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.

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.

[akidess]

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.

[RodriguezFatz]

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?

[akidess]

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).