CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

simpleFoam using kOmegaSST fully resolved

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 18, 2020, 19:50
Question simpleFoam using kOmegaSST fully resolved
  #1
Member
 
Tom
Join Date: Apr 2017
Posts: 50
Rep Power: 9
tom.opt is on a distinguished road
Hi All,


I have a very fine mesh of a turbomachinery component.
The value of y+ is smaller than 1.
I want to run simpleFoam with the flow being fully resolved near the walls.
My understanding is that the parameters which need to be modified are k, omega and nut.
My question is what should they be set to? is it zeroGradient for all the walls.
I'm running OpenFOAM v1906


Currently i have them like this:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object k;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 2 -2 0 0 0 0];

internalField uniform 7.18;

boundaryField
{
INLET-001
{
type turbulentIntensityKineticEnergyInlet;
intensity 0.0435;
value $internalField;
}
EXIT-001
{
type inletOutlet;
inletValue uniform 7.18;
value $internalField;

}
MERGEOGV-001
{
type kqRWallFunction;
value $internalField;
}
MERGEHUB-001
{
type kqRWallFunction;
value $internalField;
}
MERGECAS-001
{
type kqRWallFunction;
value $internalField;
}










FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object omega;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 -1 0 0 0 0];

internalField uniform 4502;

boundaryField
{
INLET-001
{
type inletOutlet;
inletValue uniform 4502;
value $internalField;
}
EXIT-001
{
type inletOutlet;
inletValue uniform 4502;
value $internalField;

}
MERGEOGV-001
{
type omegaWallFunction;
value $internalField;
}
MERGEHUB-001
{
type omegaWallFunction;
value $internalField;
}
MERGECAS-001
{
type omegaWallFunction;
value $internalField;
}






FoamFile
{
version 2.0;
format ascii;
class volScalarField;
location "0";
object nut;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 2 -1 0 0 0 0];

internalField uniform 0;

boundaryField
{
INLET-001
{
type calculated;
value uniform 0;
}
EXIT-001
{
type calculated;
value uniform 0;
}
MERGEOGV-001
{
type nutkWallFunction;
value uniform 0;
}
MERGEHUB-001
{
type nutkWallFunction;
value uniform 0;
}
MERGECAS-001
{
type nutkWallFunction;
value uniform 0;
}
tom.opt is offline   Reply With Quote

Old   February 20, 2020, 05:48
Default
  #2
Senior Member
 
Andrea
Join Date: Feb 2012
Location: Leeds, UK
Posts: 179
Rep Power: 16
Andrea1984 is on a distinguished road
Hi Tom,

in my experience with wall-resolved meshes and low-Re models, if your mesh satisfies y+ < 5 everywhere at the wall using either kqRwallFunction or fixedValue and a value ~0 for k does not make any significant difference. Either way, I would use a value close to zero since, strictly speaking

k_w = 0

is the mathematically correct BC, so it does not make sense to use the free-stream value for k at the boundaries. The same holds for other turbulent variables such as omega and epsilon.

My experience is mostly based on using the k-espilon Launder and Sharma low-Re model. For epsilon, the BC at the wall is

\varepsilon_w = \frac{2 \nu k}{y^2}

and because k \rightarrow y^2 at the wall, it follows that epsilon has a finite value. Nevertheless, for practical purposes, I have found that both fixedValue and epsilonWallFunction with value ~0 are valid approximations which lead to good results with the Launder and Sharma low-Re k-epsilon.

My experience with omega-based models on wall-resolved meshes is somehow more limited. However, theoretically \omega_w \rightarrow \infty so you can get away with using either a fixedValue or omegaWallFunction with a high value for omega at the wall. A more precise estimation of this "high" value can be obtained by considering that the asymptotic behaviour at the wall is \omega \rightarrow 1/y^2. The wall value for omega is then

\omega_w = 10  \frac{6 \nu}{d_1 y^2}

To sum it up, for "proper" wall-resolved meshes and low-Re turbulence models the influence of wall functions is somehow limited in my experience. A mathematically sound fixedValue for the turbulence variables at the wall should be enough (I have tested this in several cases with the Launder and Sharma k-epsilon, my experience with omega-based models is somehow more limited). In any case, sound values for the turbulence variables at the wall should be used with both fixedValue and wall functions BC types - using free stream values is conceptually wrong and can lead to numerical issues as well.

Hope this helps,
Andrea

Last edited by Andrea1984; February 20, 2020 at 07:31.
Andrea1984 is offline   Reply With Quote

Old   February 20, 2020, 07:08
Default
  #3
Member
 
Tom
Join Date: Apr 2017
Posts: 50
Rep Power: 9
tom.opt is on a distinguished road
Quote:
Originally Posted by Andrea1984 View Post
Hi Tom,

in my experience with wall-resolved meshes and low-Re models, if your mesh satisfies y+ < 5 everywhere at the wall using either kqRwallFunction or fixedValue and a value ~0 for k does not make any significant difference. Either way, I would use a value close to zero since, strictly speaking

k_w = 0

is the mathematically correct BC, so it does not make sense to use the free-stream value for k at the boundaries. The same holds for other turbulent variables such as omega at epsilon.

My experience is mostly based on using the k-espilon Launder and Sharma low-Re model. For epsilon, the BC at the wall is

\varepsilon_w = \frac{2 \nu k}{y^2}

and because k \rightarrow y^2 at the wall, it follows that epsilon has a finite value. Nevertheless, for practical purposes, I have found that both fixedValue and epsilonWallFunction with value ~0 are valid approximations which lead to good results with the Launder and Sharma low-Re k-epsilon.

My experience with omega-based models on wall-resolved meshes is somehow more limited. However, theoretically \omega_w \rightarrow \infty so you can get away with using either a fixedValue or omegaWallFunction with a high value for omega at the wall. A more precise estimation of this "high" value can be obtained by considering that the asymptotic behaviour at the wall is \omega \rightarrow 1/y^2. The wall value for omega is then

\omega_w = 10  \frac{6 \nu}{d_1 y^2}

To sum it up, for "proper" wall-resolved meshes and low-Re turbulence models the influence of wall functions is somehow limited in my experience. A mathematically sound fixedValue for the turbulence variables at the wall should be enough (I have tested this in several cases with the Launder and Sharma k-epsilon, my experience with omega-based models is somehow more limited). In any case, sound values for the turbulence variables at the wall should be used with both fixedValue and wall functions BC types - using free stream values is conceptually wrong and can lead to numerical issues as well.

Hope this helps,
Andrea





Hi Andrea,
Many thanks for your detailed answer.
What about setting all the walls to zeroGradient, would this not switch off the wall function?



Best Regards,
Tom
tom.opt is offline   Reply With Quote

Old   February 20, 2020, 07:28
Default
  #4
Senior Member
 
Andrea
Join Date: Feb 2012
Location: Leeds, UK
Posts: 179
Rep Power: 16
Andrea1984 is on a distinguished road
Hi Tom,

that would deactivate the wall-functions indeed, but from my previous post I would say that a Dirichlet (fixedValue) wall BC is more physically and mathematically sound for turbulence variables than a Neumann (zeroGradient). As far as I am aware, there is nothing in the equations for k, epsilon or omega that justifies a zeroGradient condition at the walls.

Andrea
Andrea1984 is offline   Reply With Quote

Old   February 20, 2020, 07:33
Default
  #5
Member
 
Tom
Join Date: Apr 2017
Posts: 50
Rep Power: 9
tom.opt is on a distinguished road
Quote:
Originally Posted by Andrea1984 View Post
Hi Tom,

that would deactivate the wall-functions indeed, but from my previous post I would say that a Dirichlet (fixedValue) wall BC is more physically and mathematically sound for turbulence variables than a Neumann (zeroGradient). As far as I am aware, there is nothing in the equations for k, epsilon or omega that justifies a zeroGradient condition at the walls.

Andrea
Thanks,
Having had a more through search on the internet seems that the value 1.0e-11 is often suggested for k at wall when trying to resolve the viscous sublayer.
In the last equation you quoted what is the d_1 parameter?
Also what do you set nut at the wall to?



Tom
tom.opt is offline   Reply With Quote

Old   February 20, 2020, 07:40
Default
  #6
Senior Member
 
Andrea
Join Date: Feb 2012
Location: Leeds, UK
Posts: 179
Rep Power: 16
Andrea1984 is on a distinguished road
Yes 10e-11 is a numerical way of saying zero, because that is the proper BC for k at the wall

d1 is a model constant for k-omega SST (or maybe is beta1? sorry I can't remember). Its value should be 0.075.

For nut, from the discussion above, I would say either a lowRe wall function or a fixedValue ~0.

Andrea
Andrea1984 is offline   Reply With Quote

Old   March 2, 2020, 09:06
Default
  #7
Member
 
Tom
Join Date: Apr 2017
Posts: 50
Rep Power: 9
tom.opt is on a distinguished road
Update:
I have tried applying fixedValue 1.0e-11 for k
fixedValue 8.33e9 for omega
and fixedValue 1.0e-11 for nut


Using first order upwind schemes for U, k, omega i managed to get a residual drop of over 8 levels.


Quote:
divSchemes
{
default none;
div(phi,U) bounded Gauss upwind;
div(phi,k) bounded Gauss upwind;
div(phi,omega) bounded Gauss upwind;
div((nuEff*dev2(T(grad(U))))) Gauss linear;

}

One problem i seem to be encountering though is that time step continuity error is quite high :
Quote:
Time = 24400

smoothSolver: Solving for Ux, Initial residual = 1.7750789e-11, Final residual = 1.5504266e-12, No Iterations 14
smoothSolver: Solving for Uy, Initial residual = 6.0729181e-12, Final residual = 5.2382883e-13, No Iterations 14
smoothSolver: Solving for Uz, Initial residual = 7.3039264e-12, Final residual = 6.4977959e-13, No Iterations 14
GAMG: Solving for p, Initial residual = 3.435101e-10, Final residual = 3.415404e-11, No Iterations 7
time step continuity errors : sum local = 4.2106859e-07, global = 3.6180786e-08, cumulative = -207.43149
smoothSolver: Solving for omega, Initial residual = 2.1732599e-14, Final residual = 1.7376112e-15, No Iterations 2
smoothSolver: Solving for k, Initial residual = 3.3652759e-12, Final residual = 3.146066e-13, No Iterations 12
bounding k, min: -6.3522301e-12 max: 103.92671 average: 7.2356095
ExecutionTime = 162441.55 s ClockTime = 163479 s
I changed my fvSchemes to second order


Quote:
divSchemes
{
default none;
div(phi,U) bounded Gauss linearUpwind grad(U);
div(phi,k) bounded Gauss linearUpwind grad(k);
div(phi,omega) bounded Gauss linearUpwind grad(omega);
div((nuEff*dev2(T(grad(U))))) Gauss linear;

}

It seems now that the residuals start quite high



Quote:
Time = 24401

smoothSolver: Solving for Ux, Initial residual = 0.0018588376, Final residual = 0.00016061359, No Iterations 11
smoothSolver: Solving for Uy, Initial residual = 0.0012371765, Final residual = 0.00011241854, No Iterations 11
smoothSolver: Solving for Uz, Initial residual = 0.001237139, Final residual = 0.00011238287, No Iterations 11
GAMG: Solving for p, Initial residual = 0.011627925, Final residual = 0.0011450984, No Iterations 8
time step continuity errors : sum local = 12.119613, global = 1.8224938, cumulative = -205.609
smoothSolver: Solving for omega, Initial residual = 9.9655015e-06, Final residual = 5.9330327e-07, No Iterations 3
smoothSolver: Solving for k, Initial residual = 0.0040558584, Final residual = 0.00033153192, No Iterations 11
bounding k, min: -1.2485358e-11 max: 107.27062 average: 7.2443786
ExecutionTime = 16.07 s ClockTime = 18 s



It also seems that after a few iterations the time step continuity error changes in the other direction:
Quote:
Time = 24712

smoothSolver: Solving for Ux, Initial residual = 0.0055660498, Final residual = 0.000506178, No Iterations 13
smoothSolver: Solving for Uy, Initial residual = 0.004749042, Final residual = 0.00044004408, No Iterations 13
smoothSolver: Solving for Uz, Initial residual = 0.0047080882, Final residual = 0.00043644484, No Iterations 13
GAMG: Solving for p, Initial residual = 0.022524863, Final residual = 0.0020521039, No Iterations 4
time step continuity errors : sum local = 24.869464, global = 4.4002756, cumulative = 201.27463
smoothSolver: Solving for omega, Initial residual = 0.8181819, Final residual = 1.1289035e-20, No Iterations 1
bounding omega, min: -2.1666086e+152 max: 4.450006e+166 average: 2.1279832e+159
smoothSolver: Solving for k, Initial residual = 0.97133457, Final residual = 1.4513884e-18, No Iterations 1
bounding k, min: -11.839077 max: 158.82418 average: 8.6251478
ExecutionTime = 2491.83 s ClockTime = 2502 s

After this, my simulation crashes. any idea what's going on?
tom.opt is offline   Reply With Quote

Old   March 3, 2020, 06:17
Default
  #8
Senior Member
 
Andrea
Join Date: Feb 2012
Location: Leeds, UK
Posts: 179
Rep Power: 16
Andrea1984 is on a distinguished road
Sorry Tom I can't see any straightforwad issue with your settings at a first glance.
Andrea
Andrea1984 is offline   Reply With Quote

Reply

Tags
fully resolved, komega sst model, simplefoam, yplus


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Airfoil with simpleFoam and kOmegaSST: high drag values? Tsiolkovsky OpenFOAM Running, Solving & CFD 6 November 21, 2018 06:56
simpleFoam: switching flow direction with kOmegaSST RAS Model JasonG OpenFOAM Running, Solving & CFD 1 September 25, 2014 08:26
simpleFoam with kOmegaSST ilpaso OpenFOAM Running, Solving & CFD 11 April 7, 2014 07:12
fully developed channel with cyclic using simplefoam ArathoN OpenFOAM Running, Solving & CFD 4 February 21, 2014 10:53
simpleFoam kOmegaSST LowRe pressure divergence Pat84 OpenFOAM Running, Solving & CFD 2 August 12, 2013 18:42


All times are GMT -4. The time now is 18:21.