[vvqf]

dear all,

I am now caculating a model(small mesh: 20000 cells, big: 1000000 cells) created in ICEM CFD(converting to OpenFoam by fluentMeshToFoam) with simpleFoam, but whichever mesh i use, I cant get the convergent solution. also tried reducing the timestep from 1s to 0.01s, but wouldn't help.
time step continuity errors increase fast.

but i got satisfying solution solving the same finer meshed model with ANSYS-CFX.

anyone could be so kind to give any suggestion?

PS:
parameters in the transportation file were same as in the simpleFoam tutorial case.
And fvScheme are Gauss and upwind. If i should change a better scheme, which one would you recommend?

Thank you.

[hjasak]

simpleFoam is a steady-state solver and changing the time-step size will do nothing at all (just change the names of output directories).

You should play around with the under-relaxation factors in the

system/fvSolution file:

relaxationFactors
{
p 0.2;
U 0.7;
k 0.5;
epsilon 0.5;
R 0.7;
nuTilda 0.7;
}

change the default convergence on the pressure equation in the same file:

solvers
{
p ICCG 1e-06 0.001;

check if your k and epsilon are bounded (any warnings in the log file), adjust the spatial discretisation, play around with non-orthogonal correctors, try a limited laplacian scheme on k and epsilon (if appropriate, depending on the mesh) and similar.

Good luck,

Hrv

[vvqf]

The mesh is hybrid, tet + prism + hex, + few pyramids. The cells are around 300 000.

I did as you suggested above, and chose limited linear divScheme for k and epsilon, limitedLinearV divScheme for U, and tried some higher order schemes, but still time step continuity errors increase.

Concerning the non-orthogonal correctors, I first used 10, slow, didn't help. each timestep more than 200s, and keeps increasing.
Now am trying 20 as suggested in UserGuide U-114. it is extremely slow, I'm wondering should i stop the computation.

[hani]

You can try the following:

Initialize the flow as good as possible, set some relevant constant value for k and epsilon in the internal field. Use potentialFoam to initialize the velocity.

Use upwind scheme initially for U,k,epsilon, and later change to a better scheme.
Under-relax as proposed by Hrv.
Decrease the Reynolds number by increasing the viscosity or lower the velocity, and later change back to the real Reynolds number.

Use stabilizing boundary conditions. Typically a Dirichlet condition for the pressure at the outlet seems more stable than a Neumann bc. You can later try to switch back to the bc's you really want.

Håkan.

[groens]

Dear Vvqf,
I am also a CFX-User and trying to do some comparison to OpenFOAM.
Ho did you export your mesh from ICEM to Fluent?
Everytime I when I convert the mesh I get error-messages from fluentMeshToFoam(see below).

I am using a pure hexa mesh exporting as unstructured. So far I never had a problems with CFX.

Thanks in advance
Thomas

Here is the beginning of the error messages:
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.2 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : fluentMeshToFoam . . fluent.msh
Date : Feb 02 2006
Time : 16:03:10
Host : arianna
PID : 10095
Root : /romeo_home/groens/OpenFOAM/groens-1.2/run/movingIcoSFD
Case : .
Nprocs : 1
Create time

Dimension of grid: 3
Number of points: 12000
Reading points
Number of cells: 9044
Reading uniform cells
number of faces: 29945
Reading uniform faces
Reading uniform faces
Reading uniform faces
Reading uniform faces
Reading uniform faces
Reading zone data
Reading zone data
Reading zone data
Reading zone data
Reading zone data
Reading zone data


FINISHED LEXING


dimension of grid: 3
Creating shapes for 3-D cells
Creating patch for zone: 15 start: 1 end: 24319 type: interior name: int_MDL_CRVS
Patch 15 contains solid or internal faces. Not added to boundary
Adding to internal boundaries
Creating patch for zone: 16 start: 24320 end: 24471 type: wall name: MIRROR
Creating patch for zone: 17 start: 24472 end: 24947 type: wall name: ROTOR_AUS
Creating patch for zone: 18 start: 24948 end: 29469 type: wall name: VOLUMEN
Creating patch for zone: 19 start: 29470 end: 29945 type: wall name: WAND

Default patch type set to empty
Checking mesh
--> FOAM Serious Error :
From function bool primitiveMesh::checkClosedCells(const bool report, labelHashSet*) const
in file meshes/primitiveMesh/primitiveMeshCheck.C at line 289
9044 high aspect ratio cells found. Max aspect ratio: 2.63847e+199
--> FOAM Warning :
From function primitiveMesh::checkFaceDotProduct(const bool report, labelHashSet* setPtr) const
in file meshes/primitiveMesh/primitiveMeshCheck.C at line 534
Severe non-orthogonality detected for face 0 between cells 0 and 1: Angle = 180 deg.
--> FOAM Warning :
From function primitiveMesh::checkFaceDotProduct(const bool report, labelHashSet* setPtr) const
in file meshes/primitiveMesh/primitiveMeshCheck.C at line 534
Severe non-orthogonality detected for face 1 between cells 0 and 4: Angle = 179.991 deg.

[mattijs]

Sounds like your cells are defined inside out or rather the converter expects the numbering of the vertices of a hex to be in a certain order. See the User Guide (section 6 I believe) on what Foam expects.

Try creating a 1 hex mesh and put some print statements in the converter where it creates a the cellShape. E.g.

Pout<< cellShapes[cellI] << endl;

and see if you can figure out what needs to be changed.

[groens]

Hello Mattjis,
thanks for your quick answer.

You put me on the right way.
I just built up my grid from scratch and found out that it is working when I create my mesh with another block orientation.
I think the problem is in the vertice-numbering.
I didn't expect this problem as the export function of icem is explicitely for an unstuctured mesh type.
Found a check-mesh function in icem which I never had to use during the last 4 years.

Anyway, thanks a lot one more time.

Thomas

[vvqf]

BTW, OpenFoam also offers the Checkmesh utility.

The turbulence model I chose for simpleFoam is k-epsilon model.
I want to use SST model, but it is not available in OpenFoam.

Do you think RNGkEpsilon might be a better choice?

[vvqf]

As Håkan suggested, I did first a potentialFoam calculation. And it seems now to be convergent, the time step continuity errors is decreasing slightly.
But the computing time increase, and from 5th timestep, it needs over 20 minutes(1200+s).

non-orthogonal correctors is set to 6.

any way to improve?

ps: 2-cpu machine, 3G mem.

[eugene]

Have you tried upwind? Also, check if you are getting inflow at the outlet. That is the most common source of instability.

For simpleFoam, non-orthogonal correctors do not always improve convergence (at least in my experience), more than 1 is probably overkill. I would try with different values and see how the simulation reacts.

[vvqf]

Yes, the outlet. I just have problem there.

I tried upwind, and the outlet pressureOutlet, but without initializing U with potentialFoam.

The boundary condition I want for the outlet is openning. Later I swithed to pressureInletOutlet. Under inletOutlet, there are 3 other options. But i dont know what are they for, like freeStream and atmosphere. dont know which to choose.

Thank you!

[gaby]

Hello!

I am calculating a model created in OpenFOAM (using blockMesh), with simpleFoam, but I can't get the convergent solution (incompresible flow). The geometry is similar to the nozzle2D case used in cavitatingFoam

BC==> back and front: wedge, inlet and outlet pressure: positive values normalized by density, inlet and outlet velocities: zeroGradient, Wall velocity: fixedvalue (0 m/s)

The problem is that Ux, Uy, k and epsilion converged, but Uz never converged.... I've played with all relaxation factors, solvers, fvSchemes.... and it didn't get better

Anyone could be so kind to give any suggestion? or explain why this Uz never converged

Thank you!

Gaby

[dplucenio]

Hello Gaby, I am using OpenFOAM to simulate flow in a duct, using the wedge geometry and axisymmetric condition. I am having the same problem with Uz that you had years ago. Did you find out how to manage tha problem with Uz convergence?

Thanks in advance,
Regards

Originally Posted by gaby

Hello!

I am calculating a model created in OpenFOAM (using blockMesh), with simpleFoam, but I can't get the convergent solution (incompresible flow). The geometry is similar to the nozzle2D case used in cavitatingFoam

BC==> back and front: wedge, inlet and outlet pressure: positive values normalized by density, inlet and outlet velocities: zeroGradient, Wall velocity: fixedvalue (0 m/s)

The problem is that Ux, Uy, k and epsilion converged, but Uz never converged.... I've played with all relaxation factors, solvers, fvSchemes.... and it didn't get better

Anyone could be so kind to give any suggestion? or explain why this Uz never converged

Thank you!

Gaby