[skabilan]

Hi All,

I need some help with simpleFoam. Here is my problem... I am simulating airflow through the following structure.




The boundary conditions include zero pressure at the outlet (largest cylinder) and the eight inlets are prescribed a constant pressure of 13 pa. The problem converges with out a problem.

I have another mesh which consists of only three cylinders (subset of the above problem) as shown below.



Once again the outlet (largest cylinder) is maintained at zero and the two inlets are prescribed a pressure of 6 pa (this was the average pressure at the the same locations obtained from the first simulation). The problem does not converge. The solver setting remain the same as the first simulation.

Thanks all in advance!
Senthil

[skabilan]

Hi All,

Below is the output from checkMesh for the case that does not converge.

bigbox76% checkMesh . weibel_2gen_ss_pos6
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.4.1 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : checkMesh . weibel_2gen_ss_pos6
Date : Sep 08 2008
Time : 09:50:59
Host : bigbox
PID : 5555
Root : /files0/skabilan/uw_workdir/openfoam/weibel/weibel_pressure_simulation
Case : weibel_2gen_ss_pos6
Nprocs : 1
Create time

Create polyMesh for time = constant

Time = constant

Mesh stats
points: 135357
edges: 934993
faces: 1589196
internal faces: 1569040
cells: 789559
boundary patches: 4
point zones: 0
face zones: 0
cell zones: 0

Number of cells of each type:
hexahedra: 0
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 789559
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
inlet 1548 799 ok (not multiply connected)
out2 538 281 ok (not multiply connected)
out3 663 346 ok (not multiply connected)
w1 17407 8751 ok (not multiply connected)

Checking geometry...
Domain bounding box: (-0.0341182 -0.0678843 -0.00901863) (0.0348 0.106513 0.00904051)
Boundary openness (-4.71605e-17 2.01321e-17 -6.00016e-17) OK.
Max cell openness = 6.12672e-16 OK.
Max aspect ratio = 17.4782 OK.
Minumum face area = 3.1167e-10. Maximum face area = 1.90368e-06. Face area magnitudes OK.
Min volume = 7.24431e-15. Max volume = 5.97908e-10. Total volume = 4.3833e-05. Cell volumes OK.
Mesh non-orthogonality Max: 84.0588 average: 33.8839
*Number of severely non-orthogonal faces: 5045.
Non-orthogonality check OK.
<<Writing 5045 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 2.12424 OK.
Min/max edge length = 2.42777e-05 0.00284903 OK.
All angles in faces OK.
All face flatness OK.

Mesh OK.

End

[skabilan]

Hi All,

Is the Non-orthogonality in the checkMesh the cause for the convergence problem?

Thanks in Advance
Senthil

[louisgag]

Senthil: that is a possibility (84 is pretty high). Try increasing the nNonOrthogonalCorrectors value in you system/fvSolution dictionary. Or even better, try to make the mesh more orthogonal.

[skabilan]

Hi Gagnon,

Thanks for the suggestion. The mesh did produce good results for a simple positive pressure simulation (i.e, positive pressure at the inlet and 0 pressures at the outlets). It looks like it might be a problem with the boundary type that I am specifying in /0/p and /0/U file for the following steadystate case. What boundary conditions needs to be specified for the following case?



Thanks in advance
Senthil

[louisgag]

I am not sure about this. However, when I run my simulations I always prescribe a pressure on the outlet, a velocity on the inlet and have velocity on outet as zerogradient and pressure at inlet as zeroGradient.

Looking at your problem, I could suggest that you set either the inlet or outlet velocity at fixedValue and leave the other one as zeroGradient, but that's just me using my hunch.

good luck,

-Louis

[s.m]

Originally Posted by louisgag

Senthil: that is a possibility (84 is pretty high). Try increasing the nNonOrthogonalCorrectors value in you system/fvSolution dictionary. Or even better, try to make the mesh more orthogonal.

hi louis
what do you mean "try to make the mesh more orthogonal" ?
how should we make the mesh more orthogonal, if we use SnappHexMesh for doing th mesh, we should increase the "maxNonOrtho 45;" e.g to 65 or else?