[ffucile]

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]

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]

Originally Posted by ffucile

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

Originally Posted by lord_kossity

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

Originally Posted by lord_kossity

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]

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.

this mesh is a compromise for a wide range of Re

You should not make too much compromises when it comes to the grid!

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]

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]

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]

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]

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]

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