Abrupt fall in k residuals while using realizable k-epsilon
 

Hello FOAMers,


I am trying to model the flow in a polymer treatment tank with a relatively simple geometry - essentially a rectangular apparatus in which the liquid enters through two large pipes fitted on the two opposite walls. Both the pipes are also bifurcated (before the main entrance to the tank) by means of an auxiliary pipe to send a portion of the main pipe's flow to the top portion of the tank. See the attached figures.

I noticed that using realizable k-epsilon model to simulate the tank results in a strange and unusual residual behavior. After about 80 iterations, the turbulent kinetic energy (k) residual drops all of a sudden to very low levels and k equation is not solved further. Beyond this point, the residuals of all other quantities continues to drop in the usual gradual, steady manner.

I feel that this behavior is not physical and the "converged solution" is not accurate because the k eqn. is not solved together with other quantities. Have anyone experienced such a behavior with the realizable k-epsilon model? What can I do to overcome this problem?

The problem doesn't seem related to the mesh - mesh check returns with all the usual quality parameters within their allowed limits. Here is the case attached. Steps to reproduce:

> blockMesh
> surfaceFeatureExtract
> snappyHexMesh -overwrite
> simpleFoam > log

I appreciate help from anyone.


-Kumar

Hi,


I am facing the same issue with realizable k-epsilon turbulence model. I am doing an axisymmetric multiphase flow simulation of flow in a cylindrical nozzle wherein cavitation occurs near the nozzle inlet. The residual of turbulent kinetic energy (k) drops below 10^-7 (tolerance) and then the k equation is no longer solved, which is evident from the k field frozen in time without reaching the steady state. I am using OpenFOAM v2012 and cavitatingFoam solver, with total pressure boundary condition at inlet and outlet for pressure. For velocity, I have used pressureInletVelocity at inlet and pressureInletOutletVelocity at outlet. Any ideas?

In system/fvSolution replace

"(U|k|epsilon|R|nuTilda)"
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-05;
relTol 0.1;
}

by

"(U|k|epsilon|R|nuTilda)"
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-05;
relTol 0.1;
minIter 1;
}

to ensure that k (and other fields) is always solved for, and thus updated with other fields.

I have further noticed that this bahavior most likely happens when, at some point during the course of iterations, the y+ values on some part(s) of wall patches fall below 1. Realizable k-epsilon doesn't seem to handle such situations. What are your minimum y+ values on the individual boundary patches?

Hello Kumar,

I have the same problem for a jet releasing into tank. K iterations goes to zero after a while. Moreover, the results of nut are not seem to be correct. They show higher values out of the jet flow body than inside it while the surrounding environment is stagnant. Have made any further progress in this issue?


Sina

Hello Sina,

I have seen the same problem on a couple of occasions while using the realizable k-epsilon model. The standard k-epsilon is less prone to this issue. When this happens, k residuals are found to abruptly fall over a few iterations to a level where k iterations goes to zero. Beyond that point, nut will not be correct as k equation is not solved and coupled with the flow solution. In this case, the results are obviously unreliable.

From the limited investigations that I have done, it happens when the y+ values at one or more patches happen to be less than 1. This can happen when the patch-adjacent fluid velocities are so low (although they may be high at other locations in the domain). My first thoughts: How big is your domain? Please run a yPlus check on all your walls and see the results.


-Kumar

I think k-epsilon models are not designed to handle wall y+ values less than 1; when this happens, the patch k value calculations are not realistic and fall to very low levels and these values then spoil the k-solution in the adjacent fluid cells. A remedy would be to make the grid coarser above patches with y+ < 1 until y+ becomes more than 2 or higher and see if the problem persists.


Kumar

Thank you for your reply Kumar. I read your past experience and tried to pay attention to the Y plus role. I have tank with stagnant condition inside. The jet is ejected through a circular nozzle into the domain. To see the effects of the yplus, or walls more generally speaking, I tested different scenarios in which side and bottom and back and top surfaces of the domain, i.e. the tank, are considered walls or zero gradient open boundaries. I would add that the boundaries are considered far from the jet flow so that they won't have instant impact on the flow. The result of such comparisons, was noting but failure. Again, initial residual of the k falls falls abruptly and then consequently results into zero iteration situation, halting the k equation to be solved afterwards, as you mentioned. I would conclude that the effects of the y plus , is not the case in this setup. However, since the flow is almost in its initial developments, the y plus values are , on the far walls, small, since there is no flow around them, an no important shear, velocity gradient, ...
I've also been trying different Schemes and Solution in System settings. Moreover, different inlet B.C. for k and epsilon were tried out. Mesh was carefully refined around to make sure there is no sudden change in the gradients close to the nozzle.


Sina

Is it possible to post your boundary conditions? Do you see this problem with the standard k-epsilon model?

Thank you for your prompt reply. I would post more info and helpful graphical representatives, as soon as I can.
Just as a quick reply, the standard k epsilon does not show this problem. The nut distribution is quite reasonable!
another side note: before k iteration goes to zero, it shows bounding error for a couple of time steps ahead of the abrupt fall in the residual level. However, it does not lead to any divergence or crash, as sometimes bounding error does. The run continues, without stability problem, long after the number of iterations for k has turned to zero.



Sina

Just a quick reply before I think of other things: If the standard k-epsilon doesn't show this problem, just check the y+ of converged solution on all patches designated as walls. Please let me know.


Bounding error usually indicates a mesh imperfection, but in many cases it resolves itself in the course of iterations (as the solution proceeds to convergence). Just use bounded Gauss upwind on all the divergence terms - the bounding errors should disappear.