[sreeyuth]

Hi Foamers,

I am using simpleFoam (kEpsilon with LaunderSharma turbulence model) to calculate wind flow in a rectangular channel whose floor is an actual rough surface imported as an STL file, and integrated into the wind flow domain using snappyHexMesh. I performed similar simulations on other STL files and I got good results. However, for this particular configuration, I am getting an error. My first guess is that it is purely a meshing problem since that is the only thing which has changed from the earlier successful simulations.

The following is the (retracted) result from checkMesh:

Checking topology...
Boundary definition OK.
Cell to face addressing 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
wall1 53278 60333 ok (non-closed singly connected)
wall2 46861 51743 ok (non-closed singly connected)
wall3 144197 147637 ok (non-closed singly connected)
wallRH 15231 19431 ok (non-closed singly connected)
side 144000 145642 ok (non-closed singly connected)
inlet 10000 10201 ok (non-closed singly connected)
outlet 10000 10201 ok (non-closed singly connected)
solid_G18_354x210 1078819 1087869 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (0.01587 -0.025 -0.13) (0.066 0.0248 0.23)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-1.65304e-15 4.771763e-14 1.427529e-17) OK.
Max cell openness = 3.157623e-16 OK.
Max aspect ratio = 961.5385 OK.
Minimum face area = 1.495e-11. Maximum face area = 6.438399e-07. Face area magnitudes OK.
Min volume = 1.86875e-15. Max volume = 3.219199e-10. Total volume = 0.0008964189. Cell volumes OK.
Mesh non-orthogonality Max: 89.8617 average: 4.806873
*Number of severely non-orthogonal faces: 11199.
Non-orthogonality check OK.
<<Writing 11199 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 1.491776 OK.
Coupled point location match (average 0) OK.

Mesh OK.

End





The log file of the solver indicates that something is wrong right from the first time step. I am posting the results of Time = 1, 14 and 15 (by when it inevitably blows up):

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model LaunderSharmaKE
bounding k, min: 1e-20 max: 1 average: 1
bounding epsilon, min: 1e-20 max: 200 average: 200
LaunderSharmaKECoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
sigmaEps 1.3;
}

No finite volume options present


SIMPLE: convergence criteria
field p tolerance 1e-15
field U tolerance 1e-15
field h tolerance 1e-15
field Yi tolerance 1e-15
field "(k|epsilon|omega)" tolerance 0.001


Starting time loop

Time = 1

smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 0.01876977, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.9999999, Final residual = 0.01429235, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 0.008325789, No Iterations 2
GAMG: Solving for p, Initial residual = 1, Final residual = 0.03556812, No Iterations 11
time step continuity errors : sum local = 0.1511613, global = 7.519363e-05, cumulative = 7.519363e-05
smoothSolver: Solving for epsilon, Initial residual = 1, Final residual = 0.03960412, No Iterations 4
bounding epsilon, min: 1e-20 max: 3893.073 average: 193.5936
smoothSolver: Solving for k, Initial residual = 1, Final residual = 0.04052763, No Iterations 4
bounding k, min: 1e-20 max: 1.671704 average: 0.9796702
ExecutionTime = 33.15 s ClockTime = 45 s


Time = 14

smoothSolver: Solving for Ux, Initial residual = 0.08128315, Final residual = 0.006629362, No Iterations 6
smoothSolver: Solving for Uy, Initial residual = 0.1603794, Final residual = 0.008839126, No Iterations 6
smoothSolver: Solving for Uz, Initial residual = 0.2944584, Final residual = 0.02775037, No Iterations 8
GAMG: Solving for p, Initial residual = 0.9999461, Final residual = 0.04969355, No Iterations 494
time step continuity errors : sum local = 1.324496e+19, global = -1.063446e+16, cumulative = -1.063446e+16
smoothSolver: Solving for epsilon, Initial residual = 1, Final residual = 0.0723455, No Iterations 20
bounding epsilon, min: 1e-20 max: 1.021401e+52 average: 4.278485e+45
smoothSolver: Solving for k, Initial residual = 1.130828e-05, Final residual = 5.623016e-09, No Iterations 2
bounding k, min: 1e-20 max: 8.030013e+34 average: 1.792708e+28
ExecutionTime = 854.48 s ClockTime = 867 s

Time = 15

smoothSolver: Solving for Ux, Initial residual = 0.02849565, Final residual = 5.883419e-05, No Iterations 14
smoothSolver: Solving for Uy, Initial residual = 0.06810458, Final residual = 0.001138023, No Iterations 16
smoothSolver: Solving for Uz, Initial residual = 0.03353419, Final residual = 0.0005778637, No Iterations 16
[18] #0 Foam::error:rintStack(Foam::Ostream&)--------------------------------------------------------------------------
An MPI process has executed an operation involving a call to the
"fork()" system call to create a child process. Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your MPI job may hang, crash, or produce silent
data corruption. The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

Local host: a9070.hpc-net.ethz.ch (PID 40382)
MPI_COMM_WORLD rank: 18

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.



More info:
I use "bounded Gauss Upwind" scheme for divergence and "Gauss linear corrected" scheme for laplacian.


As I said before, the only difference between this simulation and the ones which I successfully carried out earlier is the mesh. Could it be that the maximum Aspect ratio here (961.5) is too high (the successful one had 15)? Also, the current mesh has many severely non-orthogonal faces, but so did the successful ones. So I don't think that this is the problem.

I tried playing around with the snappyHexMesh parameters, but this is the best mesh I can get. Is there anyway to solve my problem with this mesh?

I have been stuck with this problem for weeks now. Any help will be greatly appreciated. Thank you for your time.


Cheers,
Sreeyuth.

[ssss]

There are a lot of non orthogonal faces in your mesh it will be difficult to converge it. Try increasing the nonOrthogonalCorrectors and use some refinementRegions where the nonOrthogonal faces are located

[sreeyuth]

Thanks for looking into my problem. As I wrote in my original post, the number of severely non-orthogonal faces in the simulation which ran successfully is almost double than that of the current simulation in which I am having this problem. Do you still think this is the problem?

The refinementRegions part was switched off so far in my meshing. I will look into it.

Thanks,
Sreeyuth.

[sreeyuth]

I think I have solved the problem, albeit in a not-so-ideal way. But the simulations are running nevertheless.

I followed the previous commenter's suggestion and focused on the non-orthogonal nature of my mesh. I managed to get around the problem by using non-orthogonal correctors as well as changing the discretization schemes to adapt to the non-orthogonal nature of my mesh. I followed the suggestions in this link:

http://www.dicat.unige.it/guerrero/o...sandtricks.pdf

As of now, the simulations are runing smoothly...