[joern]

Hi,

For my Diplom Thesis i'm trying to solve a NACA0012 (Ma 0.8, 1.25°) based on the Euler-Equations with OpenFOAM.

As a Solver for the Euler-Equiations i found rhoSonicfoam.
This solver semms to Solve the decoupled Euler-Equations.

My Problem with this solver is, that this Solver is absolute unstable. My Naca Profile allways gets a Courant Number of < 4e25 after a few Timesteps. It makes no difference if I lower DeltaT or chance U.
I would post my blockmeshdict here but i think this makes no sence, because i get a similar problems with the forwardstep from the tutorials.

The forwardstep is stable if i use the predefined Flow of Mach 3. If I use an other speed also this case diverges. I tried Mach 0.8, 1, 2 and 4.


I really don't understand, why this solver is unstable for other Mach numbers than 3.

Does anyone know, why this happens and/or how i can solve this problem?

If not: Is there any other Solver in OF to solve the Euler Equations?


tell me, if some more information is needed.

thx,
Jörn

PS: i use OF 1.4.1

[joern]

I have still no Idea why the solver diverges, but i have futher information.

I tried to solve my NACA0012 and forward_step test case at different Mach numbers with rhoSonicfoam and with rhopSonicfoam. Both solvers only converge at Mach 3.

I also tried to initialize U and phi with potentialfoam but it also had no effect.

[mihir1310]

i have the same trouble with rhoSonicFoam for supersonic free jet ...

i used variable timestepping as a cure, BUt that still does not cure the problem . using a coarser mesh may help

[flying]

In fact, I only would give you some guess about it. it is very possible there is no enough dissipation.As you have said, with coarser mesh, there is more dissipation. I only remember there is artificial viscous could help to give more dissipation or you need viscous term. It is only some part of memory. I wish it could be some hint.

[joern]

Thx for the replys.
A coarser mesh doesn't solve the problem. I tried a really coarse mesh with the same results.

my real problem is, that my diplom thesis is based on the Euler-Equations. I want to simulate a compressible, inviscid flow.


My idea, why these solver diverge is, that the discretisation of OF is only semi-implicit. If you look at a real div(rho*U) discretisation, you get:

Int [div(rho U)] dx = ... ~= Sum_f [rho_f U_f * S_f]

In a full implicit Method you would interpolate U_f at time n+1.
OF uses a field phi at this point but phi contains U_f*S_f at time n. At this point the Euler Equations get decoupled and the Sover can only be semi-implicit.
I think there the solver looses his stability, rather the stability of a full implicit method.


Has anyone a hint, how I can get a full implicit method in OF?

[mihir1310]

joern

ill definitely give that a try . I am a new entrant to both cfd [both theory & practice ] .

however one interesting thing is that in one similar thread [well we are not the first & last users of these solvers who face this issue] , Dr. Jasak said emphatically that there is nothing wrong in the solvers & that its all got to do with the BC & ICs .. so lets see

[joern]

i never thought, that we are the first with this problem.

This problem is too obvious, becaus the forward_step case from the tutorial has the same problem if you just change the speed U.

do you have a link to the other thread? i haven't found it.

[mihir1310]

no i do not have a link to that post .. He did not say more than that anyway. but there are many such threads on rhoSonic , rhoSimple .

[joern]

i'm not through with testing but i think i found the solution of this problem.

first of all: i think the boundary conditions of the forward_step case are wrong.

I thought about this because even the tutorial case just ran for Mach 3 and nothing else.

The (wrong) boundary conditons are:
inlet: U=fixedValue, p=fixedValue
outlet: U=zeroGradient, p=zeroGradient

I refer to Jasaks PhD Thesis. The boundary conditions should be:
inlet: U=fixedValue, p=zeroGradient
outlet: U=zeroGradient, p=fixedValue

if you give a fixed value for U and p in one cell, U just explodes in this cell after some iterations.


This change makes the forward_step case stable for Mach 2, 3, 4, 7 (tested).


with this change my NACA case ran for much longer but didn't get stable.

the real point for the rhoSonic solver is, that you have to limit the div Schemes.
I have no proof for it so at moment its just a claim, but i think this solver is very simple in his structure. If you then use a simple, unbounded Scheme it gets unstable. It will crash even for CoNum<<1.


In my first tests i used "Gauss linear" Scheme for div. Now i tested "limitedlinear 1" and the solver got stable over 15 sec simulation time with deltaT=0.0001 for Mach 0.8 and Mach 4.

And the results are ok.