|
[Sponsors] |
OpenFOAM 2.x simpleFoam and kOmegaSST convergence and wall treatment |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 24, 2013, 04:41 |
OpenFOAM 2.x simpleFoam and kOmegaSST convergence and wall treatment
|
#1 |
New Member
Stefan Gaerling
Join Date: Dec 2012
Posts: 22
Rep Power: 14 |
Dear FOAMers,
I'm currently trying to simulate the flow inside a 90° pipe step elbow with OpenFOAM 2.2. Nothing special with this geometry at this time. My boundary conditions are: Inlet: U: 30 m/s p: zeroGradient k: 3% Turbulence omega: 101 1/s nut: calculated Outlet: U: inletOutlet (with inletValue=(0 0 0) ) p: fixedValue 0 k, omega: inletOutlet (with $internalValue) nut: calculated walls: U: fixedValue (0 0 0) p: zeroGradient k: kqRWallFunction omega: omegaWallFunction nut: nutkWallFunction For my understanding: As I'm not trying to resolve the boundary layer at this time I need a Mesh with a y+ of 30<y+<300. I created the mesh in Salome with 10 prism layers with a growth rate of 1.2. yPlusRAS gives me after a few timesteps (when the velocity is distributed over the geometry) a range between 34 and 84. So no problem here !? The rest of the domain is tet-meshed. Now comes the problem: If i choose the tetmesh to be rather rough the simulation runs just fine with initial-residuals falling below 1e-5 regarding pressure. But if the tetmesh is rather fine (max. element size half of rough mesh) the residuals stop falling at about 1e-3 for pressure and oscillate at that value. As my interesting value is the pressure difference between inlet and outlet and I have read that for calculating the pressure drop correctly the boundary layer has to be resolved I wanted to try this too. But at this point I was not able to find some definitive answer on how to choose the boundary conditions to resolve the boundary layer or if the implemented kOmegaSST model from OpenFOAM 2.x is able for this at all. Further on I've read in the source code of the kOmegaSST model that wall functions are implemented. If the model itself contains wall functions do i need to specify them at the wall at all? Or am i only telling the model by the identifier "omegaWallFunction" that at this boundary the implemented Wall Function of the kOmegaSST model should be used? This confuses me somehow. Additionally (because it aren't enough questions already ) I'm not able to run ANY simulation with second order accuracy regarding k and omega. If I switch from upwind to linearUpwind grad(k or omega) the residuals also stop falling at about 1e-3 regarding pressure. So to summerize my various problems: 1 Why are my simulations not running successfully on a finer mesh? 2 What are the correct boundary conditions for wall-resolved calculations? 3 How should the initial residuals behave when solving with second order accuracy? I'm looking forward to a constructive discussion on these topics |
|
July 24, 2013, 12:29 |
|
#2 |
New Member
Join Date: Apr 2012
Posts: 1
Rep Power: 0 |
Hi!
1) Is the boundary layer mesh constant in both simulations? Have you checked that the height of the boundary layer mesh is sufficient to fit your boundary layer? If yes, your result looks actually weird... 2) If you want to resolve the boundary layers, you should change your mesh to get y+ max about 1, but your BCs should still be fine: maybe I am wrong, but if you look the code, you will discover that there is some "if" that excludes your wall functions for yPlus<yPlusLam_ (about 11.5 with default kappa and E). 3) No idea of why you get such a result... I'd rather start with first order and then skip to second when the flow is almost the same of the second-order-accuracy solution. Please let me know any further development, because at the moment I am interested in this topic too. |
|
July 25, 2013, 06:41 |
|
#3 |
New Member
Stefan Gaerling
Join Date: Dec 2012
Posts: 22
Rep Power: 14 |
Hey,
thanks for your reply. The meshes I created are of the following: Name / Cells / Y+min - y+max - y+avg / Aspect Ratio - Non-Orthogonality - Skewness / Thickness of Prism layer / n Prism layers Mesh 1 / 84k / 160 - 739 - 359 / 4,82 - 59/13 - 0,73 / 0,0286 / 3 Mesh 2 / 91k / 81 - 335 - 184 / 5,14 - 51/13 - 0,96 / 0,0143 / 3 Mesh 3 / 114k / 56 - 228 - 136 / 7,04 - 57/12 - 0,96 / 0,0286 / 6 Mesh 4 / 248k / 51 - 229 - 137 / 4,68 - 51/12 - 1,08 / 0,0143 / 6 Mesh 5 / 227k / 9 - 81 - 38 / 14,48 - 52/13 - 1,09 / 0,0031 / 3 The growth rate of the prism layers was always set to 1.2. Only Mesh 1 and Mesh 5 converged successfully. The thickness of the prism layers of mesh 5 were determined by the formulas from: http://www.cfd-online.com/Wiki/Y_plu...nce_estimation with a "goal - y+" of 30 The converged simulation was performed with the following fvSchemes input: div(phi,U) bounded Gauss linearUpwindV grad(U); div((nuEff*dev(T(grad(U))))) Gauss linear; div(phi,omega) bounded Gauss upwind; div(phi,k) bounded Gauss upwind; From my understanding this means second order velocity and first order turbulence modeling. If i switch from upwind to linearUpwind or limitedLinear 1 the results are quite the same regarding Delta P but the residuals behave completely different compared to first order turbulence. I attached the residual plots from Mesh 5 with first and second order turbulence modeling. Additionally I tried to start a second order simulation from my nearly converged first order simulation with no success either. The corresponding residual plot is attached to this post also. I will examine some more meshes and combinations tomorrow but I've got no idea whats going on here ResidualPlots: Mesh 5 first order: https://www.dropbox.com/s/9q8ubx9fg3...st%20order.png Mesh 5 second order: https://www.dropbox.com/s/58dxs7dq6y...nd%20order.png Mesh 5 second order started from nearly converged first order: https://www.dropbox.com/s/g49tdydixl...st%20order.png Greetings! |
|
July 25, 2013, 07:46 |
|
#4 |
New Member
Stefan Gaerling
Join Date: Dec 2012
Posts: 22
Rep Power: 14 |
Edit: The correct page from which i calculated my boundary mesh thickness is:
http://www.computationalfluiddynamic...t-cell-height/ |
|
July 26, 2013, 03:30 |
|
#5 |
New Member
Stefan Gaerling
Join Date: Dec 2012
Posts: 22
Rep Power: 14 |
Another thing I'm still wondering is the role of "nut" in /0 while using kOmegaSST.
In various threads I've read that you only have to place it in /0 if you want to view it in post-processing. Indeed simulations work with and without "nut" placed in /0 without problems. Other threads say you have to change its content from "nutkWallFunction" to "calculated" if you want to do LowRe-calcultions with kOmegaSST. If so then it is surely not only needed for postProcessing and not without use for the simulation itself. Could someone please give some hints on the actual use of "nut" in /0? If its content is of actual use then it would surely be nice to know what you have to write in there and why... |
|
July 26, 2013, 14:24 |
elbow-simpleFoam
|
#6 |
New Member
Juan Pablo Toro Labbe
Join Date: Jun 2013
Location: Davis CA
Posts: 7
Rep Power: 13 |
Dear Stefan:
Did you run already a simpler model, namely, the k/epsilon model? If you did not, I would recommend you to start working with this model by using simpleFoam. So you can get an idea (maybe not that rough) of the development of the boundary layer, velocity distribution and pressure drop. Then, I would jump to k/omega. That is my advice. Regards, JP |
|
August 1, 2013, 02:36 |
|
#7 |
New Member
Stefan Gaerling
Join Date: Dec 2012
Posts: 22
Rep Power: 14 |
Hey Juan,
k-Epsilon runs just fine with wall functions. Even no matter what the boundary mesh looks like. The problem is that on the same mesh if i switch to k-omega-sst after successfully working with k-epsilon the case is not converging. Even second order is working fine with k-Epsilon but i've got no chance to get k-omega-sst working for high-Re simulations reliably. |
|
Tags |
convergence, k omega sst, second order accuracy, simplefoam, wall functions |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Nearwall treatment for the kOmegaSST turbulence model | johnb | OpenFOAM Running, Solving & CFD | 3 | January 22, 2009 03:52 |