CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Divergence of rhoSonicfoam at low Mach Numbers

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 17, 2009, 13:17
Default Divergence of rhoSonicfoam at low Mach Numbers
  #1
Member
 
Joern Bader
Join Date: Mar 2009
Posts: 33
Rep Power: 7
joern is on a distinguished road
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 is offline   Reply With Quote

Old   April 17, 2009, 19:07
Default
  #2
Member
 
Joern Bader
Join Date: Mar 2009
Posts: 33
Rep Power: 7
joern is on a distinguished road
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.
joern is offline   Reply With Quote

Old   April 17, 2009, 19:40
Default
  #3
Member
 
Mihir
Join Date: Mar 2009
Posts: 40
Rep Power: 7
mihir1310 is on a distinguished road
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
mihir1310 is offline   Reply With Quote

Old   April 18, 2009, 06:26
Default
  #4
Senior Member
 
xinguang cui
Join Date: Mar 2009
Posts: 116
Rep Power: 7
flying is on a distinguished road
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.
flying is offline   Reply With Quote

Old   April 18, 2009, 08:57
Default
  #5
Member
 
Joern Bader
Join Date: Mar 2009
Posts: 33
Rep Power: 7
joern is on a distinguished road
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?
joern is offline   Reply With Quote

Old   April 18, 2009, 12:28
Default
  #6
Member
 
Mihir
Join Date: Mar 2009
Posts: 40
Rep Power: 7
mihir1310 is on a distinguished road
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
mihir1310 is offline   Reply With Quote

Old   April 18, 2009, 12:37
Default
  #7
Member
 
Joern Bader
Join Date: Mar 2009
Posts: 33
Rep Power: 7
joern is on a distinguished road
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.
joern is offline   Reply With Quote

Old   April 18, 2009, 12:39
Default
  #8
Member
 
Mihir
Join Date: Mar 2009
Posts: 40
Rep Power: 7
mihir1310 is on a distinguished road
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 .
mihir1310 is offline   Reply With Quote

Old   April 21, 2009, 05:45
Default
  #9
Member
 
Joern Bader
Join Date: Mar 2009
Posts: 33
Rep Power: 7
joern is on a distinguished road
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.
joern is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Could anybody help me see this error and give help liugx212 OpenFOAM Running, Solving & CFD 3 January 4, 2006 19:07
non-dimensional analysis in Fluent Endee FLUENT 8 September 7, 2005 17:16
Multicomponent fluid Andrea CFX 2 October 11, 2004 06:12
Compressible code at low Mach numbers Peter Main CFD Forum 7 May 15, 2003 08:12
TVD scheme at low Mach number Axel Rohde Main CFD Forum 5 August 6, 1999 03:01


All times are GMT -4. The time now is 09:35.