simpleFoam turbulent flow laminar results
 

Hi Foamers,
I'm a new user of OpenFoam, and I've to compare it with Fluent during my training period.

I'd like to set up a case of a steady state, incompressible, turbulent flow through an elbow. I wish to use the simpleFoam RAS solver, in order to use the same conditions as in Fluent.
Here are my BCs:
mass flow inlet at 0.111 kg/s
pressure outlet
the fluid is air at 200°C: rho=2.065kg/m3, nu=1.24e-05m2/s

I've used the pitzDaily case in the simpleFoam tutorial to copy the needed files, and I've changed the name of the patches/walls.
I've initialized epsilon and k with suitable values for my case according to the formula given in the User Guide.

My calculation converged. The point is the flow seems to be laminar when I look at it in Paraview, although my Re=~123000.

There is certainly a mistake in my files but I can't find it. I will appreciate some help.
I join my data but the mesh in the attached archive.

Thanks a lot for your time.

Hi Nicholas,
what kind of mesh do you use? what does checkMesh say?

You could try to decrease the URFs and increase the corrector steps in the fvSolution!
greets!
Philipp

Hello bephi,
thank you for your answer.
The elbow itself is made with tetrahedra. It has been extruded both at inlet and outlet to avoid backflow, with inflation on these extensions.

The checkMesh return Ok at each point, but I haven't the log here.

What do you mean by "decrease the URFs and increase the corrector steps" ?

I'm not at the office now (it's 19h22 here) : I'll try your advice ASAP tomorrow morning, if you are kind enough to explain me a bit more what I should do.
Have a nice day,
Nicolas

Hi! Well there are plenty of reasons which can cause a diverged solution. First of all its important to simulate with a good mesh. structured (hexaeder) meshes are in most cases the best choice but its not always possible to generate them. tetras are very flexible but not good for e.g. resolving the boundary layer.
anyway you can type "checkMesh" in your root directory and let openfoam search for bad cells and check for mesh quality criteria.

By decreasing URFs I mean the under-relaxation-factors which damp for example the gauss-seidel-iteration. your calculation will become slower but there will be less oscillations. For tetra-meshes you can change the nNonOrthogonalCorrectors to 2, 4 or even 8. try on your own what happens!

good luck!
Philipp

Ok, I'll try that tomorrow.
I should have thought for the meaning of UFRs, but I'm not yet very familiar with these English abbreviations :)
Thanks Philipp

I've had this problem many times, and in my case, it was only because I didn't check the scaling of the mesh. The mesh is not in the files you uploaded, but are you sure that the scaling of the mesh is ok?.

It's possible that some mistake in the blockMeshDict's 'convertToMeters' changes your scaling. Meaning that your mesh is in fact 10 or 100 times smaller or bigger than you think it is, changing the reynolds number, and the actual turbulence of the simulation.

good point! you can check quickly in paraview under "information" on the left side!

Hello Fran,
that's something I've checked. The mesh was made with Gambit, in mm. Here are the first lines of the file:
(0 "GAMBIT to Fluent File")

(0 "Dimension:")
(2 3)

(10 (0 1 24B60 1 3))
(10 (1 1 24B60 1 3)(
4.6786831030e+01 2.1048972954e+02 5.8483671611e+02
7.6672856638e+01 2.3030028665e+02 5.6100076424e+02
...

I've converted it using the command
fluentMeshToFoam -scale 0.001 FINAL.msh
and in the constant/polyMesh/points, I've got
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.0 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class vectorField;
location "constant/polyMesh";
object points;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


150368
(
(0.04678683103 0.2104897295 0.5848367161)
(0.07667285664 0.2303002867 0.5610007642)
...

(Sorry, but I've asked my boss and unfortunately, I'can't share the mesh :( )
Then I prompted a checkMesh:
caelinux@caelinux-desktop:~/OpenFOAM/caelinux-1.7.0/coude_incompressible_turbulent_RAS_stat$ checkMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.0 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.7.0-113391ee57bd
Exec : checkMesh
Date : Apr 05 2011
Time : 09:28:05
Host : caelinux-desktop
PID : 8403
Case : /home/caelinux/OpenFOAM/caelinux-1.7.0/coude_incompressible_turbulent_RAS_stat
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 150368
faces: 889670
internal faces: 863448
cells: 384767
boundary patches: 4
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 36600
prisms: 140850
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 207317
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
wall 7320 7442 ok (non-closed singly connected)
wall.tube 17394 8758 ok (non-closed singly connected)
pressure_outlet 742 552 ok (non-closed singly connected)
mass_flow_inlet 766 570 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-0.389344 -0.0782823 0.0148582) (0.0984713 0.278104 0.888811)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-9.95112e-17 -3.9632e-16 -2.05572e-16) OK.
Max cell openness = 7.42904e-16 OK.
Max aspect ratio = 19.7237 OK.
Minumum face area = 2.15543e-07. Maximum face area = 4.50338e-05. Face area magnitudes OK.
Min volume = 1.76068e-10. Max volume = 6.88276e-08. Total volume = 0.00178049. Cell volumes OK.
Mesh non-orthogonality Max: 63.9104 average: 13.6987
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.801036 OK.

Mesh OK.

End

As you can see, contrary to what I've written yesterday in the evening, there are not only tetrahedra but also many hexahedra ...
However, my mesh seems to be correct.

I'm now running the calculation with higher corrector steps. I'll give you feedback.

Well, I've run 1000 iterations but according to my probe points (almost at the outlet, near the center of the pipe) the calculation hasn't converged.
I join my new files in the archive (but the mesh, sorry)
As you can see on the probe_pt1_p.png, the pressure at the control point hasn't stabilized, even after 1000it.
And once again, I've got something laminar plotting U_mag in Paraview.

I've tried tons of BCs, computed many cases, and sincerely these results make me crazy ... Please, help !!!

Nicolas

Could you tell me the area of the elbow inlet?. And/or the speed you set at the inlet?

The diameter of the pipe is more or less 44.6mm what leads to an area of 0.001562m²
At the inlet I've tried a surfaceNormalFixedValue velocity at ~34m/s (the volumetric flow is 0.053753m^3/s)
I've also tried flowRateVelocityInlet with the flowRate given above.

Thanks for your help.

My last case is set up using this tutorial http://www.me.psu.edu/cimbala/Learni...e_OpenFOAM.pdf
changing the tolerance and relTol in the fvSchemes. Even if simpleFoam is steadyState, I've also changed the deltaT according to this document.
I've checked the U_mag in Paraview after 300it (just before leaving the office) and once again the flow seemed to be laminar. I haven't look at the stability with probe point.
That's something wrong with my case, but I don't know where ...

I'll try with a basic elbow tomorrow. This one is a bit elaborate (or do we say chased ?): that's why I can't share it.

With Gambit I've made a pipe with similar dimensions (already set in meters, so that I needn't a scaling).
Back in OF, I've copied the previous case, deleted the polyMesh directory, imported the new mesh with "fluent3dMeshToFoam coude.msh"
Here the checkMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.0 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.7.0-113391ee57bd
Exec : checkMesh
Date : Apr 06 2011
Time : 14:09:04
Host : caelinux-desktop
PID : 19165
Case : /home/caelinux/OpenFOAM/caelinux-1.7.0/coude_2
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 54285
faces: 154193
internal faces: 145951
cells: 50024
boundary patches: 3
point zones: 0
face zones: 1
cell zones: 1

Overall number of cells of each type:
hexahedra: 50024
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
w_paroi 7280 7350 ok (non-closed singly connected)
po 481 517 ok (non-closed singly connected)
vi 481 517 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0 -0.0223 -0.0222821) (0.605216 0.438576 0.0222821)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-1.92813e-17 -5.66629e-18 4.28967e-16) OK.
Max cell openness = 5.1923e-16 OK.
Max aspect ratio = 39.3006 OK.
Minumum face area = 9.16936e-07. Maximum face area = 0.000129444. Face area magnitudes OK.
Min volume = 1.83296e-09. Max volume = 3.77259e-07. Total volume = 0.00138719. Cell volumes OK.
Mesh non-orthogonality Max: 40.4168 average: 7.17792
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.685426 OK.

Mesh OK.

End

I let the BCs as they wer, just matching them with the new names of patches/walls
I ran the calculation in parallel, and obtained a convergence with 400it (using probe point)
The good news is that results are similar with OF and Fluent :cool:

The bad one is I really don't know why the previous case doesn't work.
Is it possible that's because the pipe is aligned with no axis, or because of the various types of cell used ?
Or, as mentionned by Fran, that's a scale problem but I can't explain why:
I've tried to import the mesh without scaling it, setting up my BCs with suitable values to keep the high Re number, but I had once again the same results ...
I'll ask my boss if I can redo the mesh.

Thanks for your help

Nicolas

Acording to both checkMeshes, there doesn't seem to be any problem in scaling, both cases have similar magnitudes in their overall dimensions.

But if the data given is correct your reynolds at the inlet is about 60.000, which should be turbulent.

Are you using non-ortogonal correctors in your first mesh?? you should have at least 1 or 2 considering you have tetrahedra and prisms in your mesh.

Could you paste here the openFoam screen output for the last steps of the simulation??

Axis alignment should not give you any trouble as long as your inlet speed vector is correct, are you shure that the speed at the inlet is exactly normal to the inlet patch?

With the first mesh, I've run the calculation with 0 and 4 non-ortogonal correctors, always with the same laminar result after 1000it. :(
For the velocity I'm pretty sure it was normal to the inlet since I used surfaceNormalFixedValue as BC, and I also tried a flowRateInletVelocity.

Unfortunately I left the office 1h ago, therefore I haven't got the log. I'll post it tomorrow morning.
Before leaving I launch a calculation over another mesh: I'll tell you if things changed.

Well, actually the problem comes from the mesh, or more exacty from the scaling.
Instead of using the scale utility in OF, I've done it directly in Gambit.
Back in OF, I've imported my mesh and used exactly the same BCs as before. According to Fran advice, I've added one non-orthogonal corrector.
That's the case I ran yesterday evening. Unfortunately, I exchanged the BCs at inlet and outlet (I was a bit tired :)), consequently I can't compare the results with those of Fluent, since the elbow is chased. However, the order of magnitude for U_mag and pressure are similar, and the flow is now turbulent.

The point is now : why the scale utility hasn't worked ?

i'm not sure which are the possible arguments for the command fuentMeshtoFoam. I'm not sure if the '-scale 0.001' works. There is an application for transforming meshes in openFoam called transformPoints.

Next time you have to scale anything I recommend you convert the mesh without any '-scale', and then run the application transformPoints -scale '(0.001 0.001 0.001)'

Anyway, considering that the correct usage for transform points is to give a vector with the scaling in every direction, I assume that this may also be valid fot fluentMeshToFoam. If that's so, your command didn't scale the mesh at all and just didn't give back any error message. you should try:

fluentMeshToFoam -scale '(0.001 0.001 0.001)' FINAL.msh

instead of

fluentMeshToFoam -scale 0.001 FINAL.msh

I've used the transformPoints utility the first times, with the same results. Then I've read somewhere that
fluentMeshToFoam -scale 0.001 *.msh
does the job. And in the points file it seems to be good.
I'll try the command you give.

Have a good week-end

It's time to close this thread.

The problem wasn't in the mesh nor the scaling. It seems I haven't given the right values for k and epsilon.
I've also changed the pressure of reference in the constant/transportProperties file

Hello everybody,

I have simulated turbulent air flow in a complex geometry at the past and I had a lot of problems concerning the values for the k-epsilon model. I am attaching a link that I found after hours searching at the internet that it was extremely helpful for my case. Maybe this can give you more insight concerning your matter. My results were far better than I expected!

http://ebookbrowse.com/tutorial-mino...-pdf-d74878981

Cheers,
Nickolas

Hi Nicolas,

Why are you mentionning a ref point for pressure in the transportProperties file?
I thought it was in the fVsolution file?

regards,

this link is broken can you please update with a new link to the PDF?