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

turbFoam vs CFX - 2D case high Re

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

Reply
 
LinkBack Thread Tools Display Modes
Old   October 16, 2009, 14:02
Default turbFoam vs CFX - 2D case high Re
  #1
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
Hi everybody

I am running a 2D simulation with turbFoam trying to match the experimental test data of Delany Sorensen paper ( Low speed drag of cylinders of various shapes) and in order to compare OF results with CFX-5 ones.
Unfortunately the solver during the run becomes unstable and finally diverge for Co number > 0.2. This mean a time consuming run comparable with the CFX one and with a lower quality of results.
So I am wondering that something is basically wrong in my simulation settings.

Description of the run:
-2D bluff body (rounded square shape)
-incompressible fluid
- high Reynolds number 1e5-1e6 (sub-trans critical region)
-unsteady RANS, kOmegaSST model for turbulence
Mesh
- box: 20D flow direction 7D transverse direction body-inlet distance 7D (yplus checked mean about 0.5)
Solver
-solver turbFoam (vers. OF 1.5 dev)

The first question is about the BC:
-inlet U and p fixedValue
-outlet U and p zeroGradient
- wall no slip condition
-top and bottom symmetry

Are the BC correct for this kind of problem? I mean, would be better to use a integral outflow condition for pressure or a freestream BC?

The second question:
-with Co>0.2 at the beginning of the vortex shedding the solution becomes unstable,the values of Cd, p and wallshearstress start to present high frequency spurious oscillations. The final results are very noisy signals that tends to diverge.

Please take a look to my fvSchemes

ddtSchemes
{
default CrankNicholson 0.9; //almost fully impliit
// default backward;
}
gradSchemes
{
default Gauss linear;
}
divSchemes
{
default none;
div(phi,U) Gauss limitedLinearV 1;
div(phi,k) Gauss upwind;
div(phi,omega) Gauss upwind;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}
laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
laplacian(DomegaEff,omega) Gauss linear corrected;
}
interpolationSchemes
{
default linear;
interpolate(U) linear;
}
snGradSchemes
{
default corrected;
}
fluxRequired
{
p;
}


So how to solve this problem saving calculation time?
thank you in advance for your comments

Fabio
ffucile is offline   Reply With Quote

Old   October 17, 2009, 13:13
Default
  #2
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
just an example of Cd plot
the green line represents the simulation with Co = 0.7 for the red one Co = 0.2
as you can see the Cd signal becomes very noisy.

Fabio
Attached Images
File Type: png Cd_plot.png (7.2 KB, 34 views)

Last edited by ffucile; October 17, 2009 at 13:36.
ffucile is offline   Reply With Quote

Old   October 19, 2009, 02:02
Default
  #3
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Quote:
Originally Posted by ffucile View Post
The first question is about the BC:
-inlet U and p fixedValue
-outlet U and p zeroGradient
- wall no slip condition
-top and bottom symmetry
Hi Fabio,

from a first glance, try to run it with:
- inlet: U fixedValue, p zeroGradient
- outlet: U zeroGradient, p fixedValue.

Andreas
lord_kossity is offline   Reply With Quote

Old   October 19, 2009, 04:39
Default
  #4
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
thank you Andreas

I am running now the simulation with the suggested BC and the signal seems to be stable now but it is quite irregular.
I don't know why but OF run does not present a well defined first armonic as in the CFX simualtion.
I hope this is a transient effect. What do you think about?

Fabio
Attached Images
File Type: png Cd_plot.png (10.8 KB, 20 views)
ffucile is offline   Reply With Quote

Old   October 19, 2009, 04:47
Default
  #5
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
I looked at your latest Cd plot. What happened at t = 1.15s?
Did you change discretization schemes there?

Just a general question: how does your controlDict look like? How did you set the values for the evaluatin of your forceCoeffs?
lord_kossity is offline   Reply With Quote

Old   October 19, 2009, 06:06
Default
  #6
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
nothing has changed just the wake become unstable. here is my controlDict
pplication turbFoam;


deltaT 1e-05;

writeControl adjustableRunTime;

writeInterval 0.05;

purgeWrite 0;

writeFormat ascii;

writePrecision 6;

writeCompression uncompressed;

timeFormat general;

timePrecision 6;

runTimeModifiable yes;

adjustTimeStep yes;

maxCo 0.2;

maxDeltaT 1.e-04;

functions // this one!
(
forces
{
type forces;
functionObjectLibs ("libforces.so"); //Lib to load
patches (HULL); // change to your patch name
rhoInf 1.185; //Reference density for fluid
CofR (0 2.1336 0); //Origin for moment calculations
}
forceCoeffs
{
type forceCoeffs;
functionObjectLibs ("libforces.so");
patches (HULL); //change to your patch name
rhoInf 1.185;
CofR (0 2.1336 0);
liftDir (0 0 1);
dragDir (0 1 0);
pitchAxis (1 0 0);
magUInf $v_inlet;
lRef 0.3048;
Aref 0.00929;
}
);

thank you for your comments
Fabio

Last edited by ffucile; October 19, 2009 at 06:46.
ffucile is offline   Reply With Quote

Old   October 19, 2009, 07:03
Default
  #7
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Well, what you can do moreover is check your lRef and Aref. Afaik Aref for 2D-calculations is lRef*cellThickness in the "empty"-direction.

Maybe you should also try to run "Gauss linear" on your divSchemes for the reason of accurateness. On the other hand this schemes of second order are often the reason for socalled "wiggles" in your solution. But give it a try!
lord_kossity is offline   Reply With Quote

Old   October 19, 2009, 07:08
Default
  #8
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
thanks again

the data in the controlDict are correct, but real problem is the wide band frequency of the signal.
anyway i'll try to change the divSchemes (div(phi,U)??).
Fabio
ffucile is offline   Reply With Quote

Old   October 19, 2009, 07:17
Default
  #9
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
I saw and see the problem

Some oscillation might be due to the transient phenomena, but the range of oscillation seems - as you already said - to high.

I can offer you to send me the case to dietzandreas(at)gmx(dot)de
lord_kossity is offline   Reply With Quote

Old   October 19, 2009, 11:55
Default
  #10
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Fabio,

I just had a collapse of the computation atfter 0.13769s of transient computation. Strange thing about it is that when I restart from the latest written timestep, the simulation passes the point where it crashed before without any problems... (See attached files)

Let's see what happens until tomorrow and if I can give any explanation for that.

Edit: One reason for diverging could be that I worked with relTol = 0.01 for p iterations. Now I changed it to relTol = 0.
Attached Images
File Type: jpg fC01.jpg (26.0 KB, 11 views)
File Type: jpg fC02.jpg (29.6 KB, 8 views)
lord_kossity is offline   Reply With Quote

Old   October 20, 2009, 02:42
Default
  #11
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Computation was not successful, same behavior as you described: Sudden increase of p and U leading to divergence.

It seems like the red cell in the attached image causes the calculation to break down. Probably you have to improve your mesh. As I see, your mesh fails one mesh check in "checkMesh".

Simplest way would be to raise your y+. For a timestep where computation still ran fine I had the following values for yPlusRAS: min: 0.0100218 max: 0.194452 average: 0.0668419. Hence you can increase the cell size and within doing so get rid of the high aspect ratio cells checkMesh is complaining about.

Best regards,
Andreas
Attached Images
File Type: jpg paraview.jpg (19.4 KB, 23 views)
lord_kossity is offline   Reply With Quote

Old   October 20, 2009, 04:26
Default
  #12
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
First of all thanks,
However it is very strange. My last results seems to be better and they is no longer diverging. I'll check the file that I provided to you.
Some other check I'll post my uptodate results.
Quote:
Originally Posted by lord_kossity View Post
It seems like the red cell in the attached image causes the calculation to break down. Probably you have to improve your mesh. As I see, your mesh fails one mesh check in "checkMesh".
You are right the aspectratio fails checkMesh but you have to consider that a for a 2D problem with low Re wall treatment it is quite impossible to avoid this problem. You can just move the problem in another place of you mesh. ( Is it correct?)
Quote:
Originally Posted by lord_kossity View Post
Simplest way would be to raise your y+. For a timestep where computation still ran fine I had the following values for yPlusRAS: min: 0.0100218 max: 0.194452 average: 0.0668419. Hence you can increase the cell size and within doing so get rid of the high aspect ratio cells checkMesh is complaining about.
You are right again, this mesh is a compromise for a wide range of Re, so in this paricular case is not so performing.
Anyway I do not understand why for CFX seems to be good enough.
B.R.
Fabio
ffucile is offline   Reply With Quote

Old   October 20, 2009, 04:40
Default
  #13
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Quote:
You are right the aspectratio fails checkMesh but you have to consider that a for a 2D problem with low Re wall treatment it is quite impossible to avoid this problem. You can just move the problem in another place of you mesh.
It is not impossible. Just increase the y+ by reducing the number of cells in the boundary layer.

Quote:
this mesh is a compromise for a wide range of Re
You should not make too much compromises when it comes to the grid!

Quote:
Anyway I do not understand why for CFX seems to be good enough.
Afaik cfx has some kind of interpolation/blending over cells with way to high/low values
lord_kossity is offline   Reply With Quote

Old   October 20, 2009, 04:55
Default
  #14
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
ok, ok...you are definitely right.
I'll try to do a better mesh but my hope was to sweep across an acceptable range of Re with the some mesh...too optimistic?!.
I'm quite interested in your comment about the relTol to be set to 0. Could you explain me your point?
Fabio
ffucile is offline   Reply With Quote

Old   October 20, 2009, 05:19
Default
  #15
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
relTol compares the residual of the computed timestep to the previous one(s). In case the residuals are oscillating/building up you can run into a diverging computation even if the relTol of the residuals remains in its bounds.

Regards
lord_kossity is offline   Reply With Quote

Old   October 20, 2009, 12:57
Exclamation
  #16
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
hi Andreas
below you can find the last plot of the solution. What do you think about?
Probably your problems with the divergence of the run was my fault. Sorry.
The fvSchemes provided could be the wrong one. You can find below the raw original version (a old mixed shemes dict).
thanks again
Fabio
Attached Images
File Type: png Cd_plot_20090920.png (7.0 KB, 14 views)
Attached Files
File Type: txt fvSchemes.txt (2.0 KB, 6 views)
ffucile is offline   Reply With Quote

Old   October 20, 2009, 13:36
Default
  #17
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Hey Fabio,

you are the one with the Delany Sorensen paper

If you are awaiting periodic detachement, your Cd could be right. But for me it is not possible to say if these values are correct, especially the amplitude seems really high to me.

Andreas

Last edited by lord_kossity; October 21, 2009 at 02:42.
lord_kossity is offline   Reply With Quote

Old   October 21, 2009, 04:01
Default
  #18
New Member
 
Fabio Fucile
Join Date: Oct 2009
Posts: 9
Rep Power: 7
ffucile is on a distinguished road
The mean of Cd seems to be Cdmean = 1.2 [nd], it is 15% higher than the Delany tests one. It is the best result that I was able to get so far (with this mesh).
ffucile 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
ATTENTION! Reliability problems in CFX 5.7 Joseph CFX 14 April 20, 2010 15:45
icoFsiFoam case needed vivekcfd OpenFOAM 1 May 6, 2009 13:41
CFX 10's solutions differ from CFX 5.7's Atit Koonsrisuk CFX 4 July 26, 2006 11:59
Multicomponent fluid Andrea CFX 2 October 11, 2004 05:12
CFX 4.4 installation problem Pandu Sattvika CFX 1 December 1, 2001 05:07


All times are GMT -4. The time now is 01:31.