Hi Vesselin,

which solver did you use?
Did you look at values for k? Are they also in good agreement with the experiment?
I think you used another Re-number for SST!?

Best regards,
Timo

Hi everyone,

I am running pimpleFoam for that one.
Actually, I realized that something might have gone wrong during the simulations.
Jonathan, the curves are all shown in the previous graph, right on top of each others.

- I initialized RANS1 with the laminar solution.
- I ran all other cases starting from the converged RANS1 simulation. They all converged to almost the same result.
- This morning, I tried to run RANS6, initializing with Poiseuille's solution, and the result turned out to be really close to RANS1!

I will try to see if something went wrong in my simulations. Once everything is checked, I'll post the comparison.

Theoretically, I used the exact same Reynolds number. I included a body force (pressure gradient) so that the mean velocity converges to Uplusbar = 17.54 (same than in DNS).

Hey again,

Pretty confusing. Has any of you already seen something like this in OpenFOAM? (see picture)

For this simulation, I used the BC suggested by Jonathan. It seems that the flow converged to the wrong solution...The pressure gradient is adapted dynamically to ensure that the flow rate is constant (and imposed in the fvOptions file). However, I have several overshoots at the centerline. I guess I could simply perturb the flow (that's what I am going to try now), but it is pretty strange that OpenFOAM can't find the correct solution on its own.

Any suggestion on that one?
Thanks!

It seems that the initial conditions have a huge influence on the final solution.

I ran the exact same simulation, but using two different initial flow fields:

1. uniform flow field (U = 0.1376 m/s everywhere)
2. Poiseuille solution (parabolic velocity profile with Ubar = 0.1376 m/s)

The final solutions are attached. I believe the problem comes from the pressureGradient in the fvOptions file.

Is there another way to impose a pressure gradient in the flow?

Best regards,

Joachim

Hi Joachim,

can you upload a log-file?

hi Joachim,

I havent done any flat plate testing with adverse pressure gradients of the standard kOmegaSST model (OF2.1.1), so i cant comment too much on your results.

Also, i have not heard of fvOptions - can you direct me to a tutorial which uses this? Perhaps this will help me to understand your simulation exactly ...

PS - I have written a version of kOmegaSST with the Wilcox damping functions (which are the damping functions discussed by Henry on the forums etc) and based this almost exactly on the implementation used in Fluent. I was wondering whether you could upload your DNS data, or direct me to where i can download it - as i want to confirm the correct asymptotic behaviour of the quantities such as k / omega / nut etc near the wall, and not just u+ vs y+.

many thanks and regards
Jon

kOmegaSST with Wilcox damping functions
 

Hi All,

Attached is the code for a version of Menter's kOmegaSST model with damping functions (as discussed here http://www.openfoam.org/mantisbt/view.php?id=179). I havent validated it extensively yet, so there may be a few issues that need to be fixed, but its uploaded for anyone who would like to test / comment / fix etc.

cheers
jonathan

Hi Jonathan,

The DNS data I used were taken from

"Direct numerical simulation of turbulent channel flow up to Reτ = 590", R.D. Moser, J. Kim and N.N. Mansour, Phys. Fluids 11, 943 (1999)
http://pof.aip.org/resource/1/phfle6/v11/i4/p943_s1

The actual data are available online at this address
http://turbulence.ices.utexas.edu/MKM_1999.html

Regarding the fvOptions, it allows you to add a body force (pressure gradient here) in the flow. Apparently, I cannot upload it on this forum. You can find it here tutorials/incompressible/pimpleFoam/channel395/system/fvOptions
At each time step, it basically computes the average velocity in the flow field and compares it to a prescribed value (Ubar in transportProperties). Some kind of pressure gradient is then defined (it doesn't seem to be an actual pressure gradient, just an artificial trick that offset the velocity field so that the new average has the correct value). This tool was used in the channel flow tutorial (see Eugene De Villier's PhD thesis). For some reason, I believe it might the reason why my simulations goes wrong. I am going to change my BC and define manually the pressure gradient. I'll have to iterate a few times until I obtain the correct Retau, but at least I'll be sure of the results.

Sorry timo_IHS, the log file is pretty big. What are you looking for in there?
The residuals are very low, except for the pressure field (the residuals are really bad for that one!)

Good luck with your verification Jonathan,

Joachim

... and one time step?

I had a Courant number of 0.65 max.

I read some stuffs regarding the old channelFoam solver. It looks very similar to what the fvOptions file is doing.
I guess in the latest version of OpenFOAM, they just deleted channelFOAM and included its features in the other solvers via fvOptions.

Dear All,
I have gone through many threads regarding wall treatment for lowRe turbulence model. This thread gives me some reasonable input for my work.

I am working on axial flow fan with low Re number turbulence model (kOmegaSST), According to the discussion in this tread I have given my boundary conditions. It seems the simulation is going fine, but the convergence is very slow.

The mesh size is 21 millions, and the y+ valve is between 1 to 2. The simulation is going on with 6 processors only, I am not able to increase the number of processors due to segmentation fault problem.

I am looking for a help from some one to check my case setup.

0/k:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 2 -2 0 0 0 0];

internalField uniform 0.39;

boundaryField
{
inlet
{
type fixedValue;
value uniform 0.39;
}

outlet
{
type zeroGradient;
}

top0 (wall)
{
type fixedValue;
value uniform 1e-12;
}

top1 (wall)
{
type fixedValue;
value uniform 1e-12;
}

top2 (wall)
{
type fixedValue;
value uniform 1e-12;
}

ILR0
{
type cyclic;
}

ILR1
{
type cyclic;
}

OLR0
{
type cyclic;
}

OLR1
{
type cyclic;
}

CLR0
{
type cyclic;
}

CLR1
{
type cyclic;
}

FCLR0
{
type cyclic;
}

FCLR1
{
type cyclic;
}

center0 (wall)
{
type fixedValue;
value uniform 1e-12;
}

center1 (wall)
{
type fixedValue;
value uniform 1e-12;
}

fan (wall)
{
type fixedValue;
value uniform 1e-12;
}

}


// ************************************************** ************//

0/omega:

internalField uniform 3.7;

boundaryField
{
inlet
{
type fixedValue;
value uniform 3.7;
}

outlet
{
type zeroGradient;
}

top0 (wall)
{
type omegaWallFunction;
value uniform 1441;
}

top1 (wall)
{
type omegaWallFunction;
value uniform 1441;
}

top2 (wall)
{
type omegaWallFunction;
value uniform 1441;
}

ILR0
{
type cyclic;
}

ILR1
{
type cyclic;
}

OLR0
{
type cyclic;
}

OLR1
{
type cyclic;
}

CLR0
{
type cyclic;
}

CLR1
{
type cyclic;
}

FCLR0
{
type cyclic;
}

FCLR1
{
type cyclic;
}

center0 (wall)
{
type omegaWallFunction;
value uniform 1441;
}

center1 (wall)
{
type omegaWallFunction;
value uniform 1441;
}

fan (wall)
{
type omegaWallFunction;
value uniform 1441;
}
}

// ************************************************* //


0/nut:

internalField uniform 0;

boundaryField
{
inlet
{
type calculated;
value uniform 0;
}

outlet
{
type calculated;
value uniform 0;
}

top0 (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

top1 (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

top2 (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

ILR0
{
type cyclic;
}

ILR1
{
type cyclic;
}

OLR0
{
type cyclic;
}

OLR1
{
type cyclic;
}

CLR0
{
type cyclic;
}

CLR1
{
type cyclic;
}

FCLR0
{
type cyclic;
}

FCLR1
{
type cyclic;
}

center0 (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

center1 (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

fan (wall)
{
type nutUSpaldingWallFunction;
value uniform 0;
}

}

// ************************************************** //

0/p : zeroGradient for wall
0/U : fixedValue for wall

Please check it and give me your suggestion if I need to change something.

Thanks,
Sivakumar

The k-w SST model implemented in OpenFOAM (v2.2.0) seems to be the high-Re version. I am currently implementing the low-Re version. It should not take more than a couple of days I believe.
I'll upload it as soon as it is done.
Good luck with your case.

Dear Joachim,
Thanks for your interest, actually I am using OF-2.1.1.
if its possible please check the setup and give me your suggestions.

Thanks,
Sivakumar

There as been lots of debate whether one should use the nutUSpaldingWallFunction or not for nut. Personally, I believe that there is no real point in having y+~1 with the current SST model. The wall function for nut will provide decent answers, but it won't be as good as a low Re model. If you really want to use this high-Re version, I guess you'll get even better results if you take y+~60 and rely on wall functions completely.

I don't know if you have read this thread:
http://www.cfd-online.com/Forums/ope...komegasst.html
It is pretty cool and explains everything. :)

Hej Joachim,

will you make an announcement -- by the time the implementation is ready -- in this thread additionally to the thread for the model?

Sure. I will.
However, one little question.
For all RAS models implemented in OF, the production term is defined by 2*nut*magsqr(symm(fvc::grad(U_)), which corresponds to P = tau_{ij} S_{ij}.

However, it seems that most models (including the SST model) have been calibrated considering that P = = tau_{ij} du_i/dx_j (see various papers by Menter & al.).

Shouldn't the production term be modified as follows

G(type() + ".G", 2*nut*symm(fvc::grad(U_))&&(fvc::grad(U_)))

?

Dear Joachim,
I have done some simulation using high-re turbulence model (k-epsilon), I got nice results, but for the same case komegasst with wall function over predicts the pressure.

Now I want simulate the case with low re turb model.

Thanks,
Sivakumar

Did you try the low-Re k-epsilon model currently implemented in OpenFOAM (LaunderSharmaKE)?

not yet, I can try that now.

Please try and tell me if you get good results.
Personally, I did a low-Re simulation on a 2D airfoil using both models, and the results turned out to be far better with the LaunderSharmaKE model than with the SST (which makes sense, since one is low-Re and not the other)