CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   turbFoam vs CFX - 2D case high Re (http://www.cfd-online.com/Forums/openfoam-solving/69249-turbfoam-vs-cfx-2d-case-high-re.html)

ffucile October 16, 2009 14:02

turbFoam vs CFX - 2D case high Re
 
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 October 17, 2009 13:13

1 Attachment(s)
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

lord_kossity October 19, 2009 02:02

Quote:

Originally Posted by ffucile (Post 232951)
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

ffucile October 19, 2009 04:39

1 Attachment(s)
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

lord_kossity October 19, 2009 04:47

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?

ffucile October 19, 2009 06:06

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

lord_kossity October 19, 2009 07:03

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!

ffucile October 19, 2009 07:08

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

lord_kossity October 19, 2009 07:17

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 October 19, 2009 11:55

2 Attachment(s)
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.

lord_kossity October 20, 2009 02:42

1 Attachment(s)
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

ffucile October 20, 2009 04:26

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 (Post 233318)
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 (Post 233318)
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

lord_kossity October 20, 2009 04:40

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

ffucile October 20, 2009 04:55

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

lord_kossity October 20, 2009 05:19

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

ffucile October 20, 2009 12:57

2 Attachment(s)
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

lord_kossity October 20, 2009 13:36

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

ffucile October 21, 2009 04:01

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


All times are GMT -4. The time now is 06:18.