[ham]

Hello again.
Now I am running a simple 3dmesh with a sphere in a freestream. I am using simpleFoam.

During the first few timesteps everything looks good but after a while the magnitudes of "time-step continuity errors", "bounding epsilon" and "bounding k" increases.

Anyone knows why?
What are typical values of k and epsilon?
Is k-epsilon the same turbulence model as k-omega?

Thank you!

/Marcus

[hjasak]

Heya,

k-epsilon and k-omega (as the name suggests) are two different models. As for your problems, it seems that the discretisation needs tuning: you should not be getting the bouding messages on k and epsilon because if this continues, the solution will blow up.

For a better continuity error, try tightening the (relative) pressure tolerance - that's the second number behind p in system/fvSolution (you know where, right?)

Enjoy,

Hrv

[ham]

Thank you.

Yes, i know where.

/ham

[ham]

Okey, I tried to tightening the relative pressure tolerance and yes I got better continuity.

But I guess this is like everything else, a compromise. So when I get better continuity by tightening the pressure tolerance I must be get some negative sideeffects?

/marcus

Hi, Im having a similar problem where I get all between 50 to 1000 itterations on pressure. when choosing a relative tolerance closer to 0.9 (which is hish) I get most often only one itteration and still low values of continuity. This is what the print out looks like. Is it anything to worry about and should I modify it for a more correct answer?

Time = 0.5

BICCG: Solving for Ux, Initial residual = 0.135647, Final residual = 0.000552089, No Iterations 1
BICCG: Solving for Uy, Initial residual = 0.101647, Final residual = 0.000369054, No Iterations 1
BICCG: Solving for Uz, Initial residual = 0.0413855, Final residual = 0.000171168, No Iterations 1
ICCG: Solving for p, Initial residual = 0.0443585, Final residual = 0.0381298, No Iterations 964
time step continuity errors : sum local = 0.00204006, global = -1.59512e-05, cumulative = -0.00112614
Creating alphaEff.
BICCG: Solving for T, Initial residual = 0.237459, Final residual = 0.0189455, No Iterations 88
BICCG: Solving for epsilon, Initial residual = 0.0176145, Final residual = 8.30749e-11, No Iterations 1
BICCG: Solving for k, Initial residual = 0.147769, Final residual = 0.00053236, No Iterations 1
ExecutionTime = 22.51 s


Time = 0.6

BICCG: Solving for Ux, Initial residual = 0.238292, Final residual = 0.000707662, No Iterations 1
BICCG: Solving for Uy, Initial residual = 0.191797, Final residual = 0.000584621, No Iterations 1
BICCG: Solving for Uz, Initial residual = 0.130177, Final residual = 0.000364168, No Iterations 1
ICCG: Solving for p, Initial residual = 0.0319587, Final residual = 0.0173633, No Iterations 1
time step continuity errors : sum local = 0.00206456, global = 0.000150139, cumulative = -0.000976002
Creating alphaEff.
BICCG: Solving for T, Initial residual = 0.181806, Final residual = 0.0121908, No Iterations 89
BICCG: Solving for epsilon, Initial residual = 0.040725, Final residual = 8.54144e-11, No Iterations 1
BICCG: Solving for k, Initial residual = 0.127848, Final residual = 0.000452815, No Iterations 1
ExecutionTime = 24.83 s

Thanks
/Erik

[hjasak]

But I guess this is like everything else, a compromise. So when I get better continuity by tightening the pressure tolerance I must be get some negative sideeffects?

That is correct: the negative side-effect that you get is the fact that the pressure solver now works harder and as a consequence your simulation time is longer. If you really need bettwr convergence, this cannot be helped....

As for you Erik, try using the AMG solver, this will make it faster.

Hrv


Hrv

[yousuf]

Hi,
I'm also facing the same kind of problem. I'm working on turbfoam , in my case both epsilon and k are getting bounded and on increasing relative tolerance of either of them they still are bounding and no of iterations is reduced to "1".

What can i do to stop it from bounding.........my work has almost come to halt because of this ...please somone reply soon

[eugene]

A common cause of negative k and/or epsilon is an unbounded convection scheme. Switching div(phi,k) and div(phi,epsilon) to "Gauss upwind;" in fvSchemes generally prevents unbounded solutions.

If you are getting negative k and epsilon values despite using upwind for convection, then you probably have some very nasty cells and will have to start looking at reducing your explicit non-orthogonal correction contribution.

I must point out though that small negative k-epsilon values that cause the bounding routines to trigger are not in themselves problematic. I.e. you can run just fine with bounding removing small negative values of k and epsilon as long as there are no other problems.

[kwardle]

Hi,
I am having the same problem with a negative k that appears to be causing my case to crash. I have tried changing the div(phi,k) to upwind but still get the same problem--it crashes after about two iterations. I am using lesInterFoam. Is there maybe something wrong with my boundary specification? I have two pressureInletOutletVelocity boundaries and two fixed value velocity inlets.
Any help would be greatly appreciated!

[kwardle]

I forgot to also mention that I am using the locDynOneEqEddy LES model although I have also tried a few others and gotten the same problem.

[Tobi]

Hello Foamers,

I have a bouding problem in my geometry too, but the bouding value is:

bounding epsilon, min: 1.58155e-17 max: 0.0864828 average: 0.0667376

What is causing it?
Normally I thought high values are for bounding...
Well my pressure calculation is very bad and after 700 timesteps I get 1000 Iterations in the pressure equation. ...

I know that problem by using wrong boundary conditions but therefor its not possible to set other BC.

[Aadhavan]

Hi Tobi,
Reply can be late, even though bounding epsilon or k, it can be because of the improper initial values and the schemes which you are using for your div scheme.
while using Gauss Linear I was facing this problem, you can fix this problem changing your scheme to upwind for epsilon.

Thanks,
Aadhavan

[rmz]

Hello,

I am also facing problems with k and epsilon (and time step continuity).

I am working on a simulation of wind on buildings with a complex Mesh.
I am using a RASModel kEspilon with the simpleFoam solver.
I am applying ABL conditions (atmospheric boundary layer).

the following is the result of simpleFoam: (end of log file)

Time = 1400

--> FOAM Warning :
From function Foam::fv::gaussConvectionScheme<Type>::gaussConvec tionScheme(const Foam::fvMesh&, const surfaceScalarField&, Foam::Istream&) [with Type = Foam::Vector<double>; Foam::surfaceScalarField = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file finiteVolume/convectionSchemes/gaussConvectionScheme/gaussConvectionScheme.H at line 124
Reading "/home/ingerop/OpenFOAM/ingerop-4.1/run_Dell/PAP_run/PAP_case_06_30/system/fvSchemes.divSchemes.div(phi,U)" at line 32
Unbounded 'Gauss' div scheme used in steady-state solver, use 'bounded Gauss' to ensure boundedness.
To remove this warning switch off 'warnUnboundedGauss' in "/opt/openfoam4/etc/controlDict"
smoothSolver: Solving for Ux, Initial residual = 0.650123471409, Final residual = 0.000536065354047, No Iterations 7
smoothSolver: Solving for Uy, Initial residual = 0.474402233563, Final residual = 0.000272846612547, No Iterations 7
smoothSolver: Solving for Uz, Initial residual = 0.40187498067, Final residual = 0.000352888200821, No Iterations 7
GAMG: Solving for p, Initial residual = 2.85560731574e-09, Final residual = 3.12227411183e-11, No Iterations 1
GAMG: Solving for p, Initial residual = 1.20231286355e-15, Final residual = 1.20231286355e-15, No Iterations 0
GAMG: Solving for p, Initial residual = 1.20231286355e-15, Final residual = 1.20231286355e-15, No Iterations 0
time step continuity errors : sum local = 6.9024809888e+13, global = 10717.5469682, cumulative = 10682.7233616
smoothSolver: Solving for epsilon, Initial residual = 0.0267368427021, Final residual = 2.3236823785e-05, No Iterations 5
bounding epsilon, min: -9.83865826487e+32 max: 1.49104083956e+43 average: 9.07708546183e+36
smoothSolver: Solving for k, Initial residual = 0.99037016753, Final residual = 0.000816545910787, No Iterations 6
bounding k, min: -2.05212151592e+16 max: 5.16442351974e+35 average: 6.52272709956e+29
ExecutionTime = 29160.12 s ClockTime = 29697 s

Time = 1401

--> FOAM Warning :
From function Foam::fv::gaussConvectionScheme<Type>::gaussConvec tionScheme(const Foam::fvMesh&, const surfaceScalarField&, Foam::Istream&) [with Type = Foam::Vector<double>; Foam::surfaceScalarField = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file finiteVolume/convectionSchemes/gaussConvectionScheme/gaussConvectionScheme.H at line 124
Reading "/home/ingerop/OpenFOAM/ingerop-4.1/run_Dell/PAP_run/PAP_case_06_30/system/fvSchemes.divSchemes.div(phi,U)" at line 32
Unbounded 'Gauss' div scheme used in steady-state solver, use 'bounded Gauss' to ensure boundedness.
To remove this warning switch off 'warnUnboundedGauss' in "/opt/openfoam4/etc/controlDict"
smoothSolver: Solving for Ux, Initial residual = 1.73686761346e-09, Final residual = 1.73686761346e-09, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 8.49670942582e-09, Final residual = 8.49670942582e-09, No Iterations 0
smoothSolver: Solving for Uz, Initial residual = 7.97749175341e-10, Final residual = 7.97749175341e-10, No Iterations 0
GAMG: Solving for p, Initial residual = 3.26294168382e-05, Final residual = 2.04903628538e-08, No Iterations 5
GAMG: Solving for p, Initial residual = 1.80088423459e-12, Final residual = 1.80088423459e-12, No Iterations 0
GAMG: Solving for p, Initial residual = 1.80088423459e-12, Final residual = 1.80088423459e-12, No Iterations 0
time step continuity errors : sum local = 1.92360928162e+41, global = -3.25979779589e+25, cumulative = -3.25979779589e+25
smoothSolver: Solving for epsilon, Initial residual = 2.08398503235e-17, Final residual = 2.08398503235e-17, No Iterations 0
smoothSolver: Solving for k, Initial residual = 8.88019064951e-08, Final residual = 7.39368688472e-11, No Iterations 5
bounding k, min: -6.88777988968e+34 max: 3.77003683949e+47 average: 1.86101835569e+41
ExecutionTime = 29170.4 s ClockTime = 29707 s

SIMPLE solution converged in 1401 iterations

End

so my SIMPLE solution converged but I I have strange bounding k and epsilon:
bounding epsilon, min: -9.83865826487e+32 max: 1.49104083956e+43 average: 9.07708546183e+36
bounding k, min: -6.88777988968e+34 max: 3.77003683949e+47 average: 1.86101835569e+41

Can anyone help solve this problem?

Thank you

[mehtab]

Hi,

I am also getting a similar message.

I am trying to simulate an open large pool fire with wind effects. I am using fireFoam with ABL. My epsilon and k values are getting higher and higher and epsilon reaching upto 10^18. And courant number drops to 10^-10.

I tried relaxing pressure in fvSolution to a higher value relTol=0.9 and changed div scheme for k in fvScheme to Gauss upwind. But all in vain. Nothing is changed.

Can someone please guide me what might be wrong in this case?

Thanks
Mehtab

[rmz]

Hello Mehtab,

In my case, the problem was with the quality of the mesh; the skew faces were causing the k and epsilon to explode.
so I worked on fixing my mesh and using schemes that are less sensitive to bad quality mesh.

you can check the quality of you mesh using the utility checkMesh.

In my case, in order to fix the mesh, i changed the parameters of snappyHexMesh, I used:
-nSmoothPatch=5
-maxBoundarySkewness=3
-maxInternalSkewness=2

[mehtab]

Hi,

Thanks for the answer. I am not using snappy, I am using blockMesh. My geometry is quite simple with rectangular faces on four sides plus top and ground, and in the centre on the ground, I have fire source.

I checked the mesh and quality look acceptable to me.

Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 644885
faces: 1911936
internal faces: 1889664
cells: 633600
faces per cell: 6
boundary patches: 4
point zones: 0
face zones: 0
cell zones: 0

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

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
inlet 2880 2929 ok (non-closed singly connected)
outlet 13536 13685 ok (non-closed singly connected)
sides 2400 2525 ok (non-closed singly connected)
base 3456 3552 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-106.066 -106.066 0) (106.066 106.066 150)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (4.72868e-16 -6.75293e-18 -7.00289e-17) OK.
Max cell openness = 2.66676e-16 OK.
Max aspect ratio = 19.4052 OK.
Minimum face area = 0.0923684. Maximum face area = 44.7697. Face area magnitudes OK.
Min volume = 0.0556316. Max volume = 134.819. Total volume = 6.75e+06. Cell volumes OK.
Mesh non-orthogonality Max: 43.573 average: 13.8074
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.816862 OK.
Coupled point location match (average 0) OK.

Mesh OK.

End

Is there anything to do with LES as I am using LES with one-equation eddy model and cube-root-delta option? I am really stuck at this point, I do not understand the reason behind this absurd nature.

Please help me out of this.

[sheaker]

Hello.
Your case is really over 200meter in all directions?

What were Your relaxation factors? I had similar problem with bounding k and epsilon and relaxation factors solve the problem for me. Did You set relaxation factor for k and epsilon to (for example) 0.05?

[mehtab]

Hi,

Yes, my case is really big. I am simulating Montoir 35 m pool fire with wind condition.

Yes, I also tried with reducing relaxation factor for k to 0.05 but the result is similar. k and epsilon are shooting high values and causing delta time to be very small and the solution does not forward in time.

I am attaching the case files. Please have a look and give any clue what is wrong in the case setup. A part of the log file is attached to accommodate within size limit.

Thanks

[HappyS5]

I assume this is true for all flow geometries.

"Experimentation and previous user experience [2] have shown that the simulated results are insensitive to the discretization scheme used for the convective divergence term in the turbulence equations (for example k, ε or ω). For these equations, use of the upwind discretization scheme ensures stability and does not degrade solution accuracy. This is not the case for the convective divergence term in the momentum equation however, where different discretization schemes can have a significant effect on the results. In particular, the use of upwind discretization in the momentum equation produces significant errors. This is illustrated in detail in Section 5." [1]

Anyone disagree and have literature to show why? I am learning. It sure has made my RANS simulation more stable. The user manual says "Gauss Upwind" is considered to be too inaccurate under divergence schemes. As can be seen with the above quote, the authors verify the same for the momentum equation.

References:

[1] Jones, David A.; Liefvendahl, Mattias; Chapuis, Michael; Widjaja, Ronny; Norrison, Daniel; (2016). RANS Simulations using IpenFOAM Software. URL: https://apps.dtic.mil/dtic/tr/fulltext/u2/1002391.pdf