# Using k-omega SST to simulate simple channel flow

 Register Blogs Members List Search Today's Posts Mark Forums Read

March 4, 2014, 14:40
Using k-omega SST to simulate simple channel flow
#1
Member

Manan
Join Date: Oct 2013
Location: Göteborg
Posts: 37
Rep Power: 5
Hello people,

I have been tring to use the kOmegaSST model implemented in OF 2.2x, to simulate channel flow. I have defined the inlet and outlet as cyclic BCs, and am only evaluating for the half channel width. Moreover, depth in the z direction is one cell thick, so it is practically a 2 D channel. yPlus at the first node from wall ~ 0.75 (128 cells in the y direction).

Following are the boundary conditions for my turbulent parameters :

p

Code:
dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
inlet
{
type            fixedValue;
value           uniform 1.0;

}

outlet
{
type            fixedValue;
value           uniform 0.0;
}

fixedWalls
{
}

frontAndBack
{
type            empty;
}

middle
{
type           symmetryPlane;
}
}
U

Code:
dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
inlet
{
}

outlet
{
}

fixedWalls
{
type            fixedValue;
value           uniform (0 0 0);

}

frontAndBack
{
type            empty;
}

middle
{
type            symmetryPlane;
}
}
k

Code:
dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 0.325;

boundaryField
{
inlet
{
}

outlet
{
}

fixedWalls
{
type            fixedValue;
value           uniform 1e-10;
}

frontAndBack
{
type            empty;
}
middle
{
type            symmetryPlane;
}

}
omega

Code:
dimensions      [0 0 -1 0 0 0 0];

internalField   uniform 400;

boundaryField
{
inlet
{
}

outlet
{
}

fixedWalls
{
type            omegaWF;
value           uniform 400;

}

frontAndBack
{
type            empty;
}
middle
{
type           symmetryPlane;
}

}
Here, omegaWF is a modified omegaWallFunction which disables the re-evaluation of the production term at the first node next to the wall. Also, omega is calculated only from omegaVis (i.e. omega= omegaVis, in omegaWF) and not from omegaLog.

nut

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

internalField   uniform 0;

boundaryField
{
inlet
{
}

outlet
{
}

fixedWalls
{
type            nutLowReWallFunction;
Cmu             0.09;
kappa           0.41;
E               9.8;
}

frontAndBack
{
type            empty;
}

middle
{
type           symmetryPlane;
}

}
The Reynolds_tau has been chosen as 395, hence the laminar viscosity (nu) is defined as 1/395 in constant/transportProperties.

When I compared my results with those obtained by CFDTM (http://cfd.mace.manchester.ac.uk/twi...tCase001Res001), my graphs looked as follows:

Does anybody know the reason for this? Has anybody tried validating kOmegaSST in the past? Can somebody looking at the figures and suggest why nut starts dipping at a certain y+?

Would be grateful for any insights. Thanks
Attached Images
 U.jpg (23.9 KB, 188 views) nut.jpg (20.7 KB, 137 views) k+.jpg (25.5 KB, 135 views)

 March 4, 2014, 18:44 #2 Senior Member   ArathoN Join Date: Jul 2011 Posts: 137 Rep Power: 8 First why did you change omegaWallFunction? It works both for low-Re and High-Re meshes. Second nutLowReWallFunction is meant for yplus between 2-5 and not below 1 and for kOmegaSST use nutUSpaldingWallFunction it is a continuous wall function and it workd in high and low re meshes.

 March 5, 2014, 06:02 #3 Member   Manan Join Date: Oct 2013 Location: Göteborg Posts: 37 Rep Power: 5 Ok Thanks ArathoN. I will try this and let you know what I get. I changed the omegaWallFunction to omegaWF because my yPlus for first node was so less. Hence I did not see why omega at the first node should be calculated as a mean of both omegaVis (omega at the first node in viscous sublayer) and omegaLog (omega at the first node in the log layer). Code:  omega[faceCellI] = sqrt(sqr(omegaVis) + sqr(omegaLog)); What do you think about this? Also, do you know the reference for the re-evaluation of the production term at the first node, in the omegaWallFunction? Code:  G[faceCellI] = (mutw[faceI] + muw[faceI]) *magGradUw[faceI] *Cmu25*sqrt(k[faceCellI]) /(kappa_*y[faceI]); In general, for other turbulence models (like say v2f), if the yPlus is below 1, what is the best nutWallFunction to use?

 March 5, 2014, 06:09 #4 Member   Manan Join Date: Oct 2013 Location: Göteborg Posts: 37 Rep Power: 5 Hey ArathoN I tried with your suggestions but the result did not change much! Have you by chance tried running kOmegaSST for channel flow and validating it yourself?

 March 5, 2014, 06:15 #5 Senior Member   ArathoN Join Date: Jul 2011 Posts: 137 Rep Power: 8 Generally if yplus i below 1 you need to set nut as calculated, but for the kOmagaSST it's better to set nut as nutUSpaldingWF (this was specified by the developer who implemented the model). For omega i think it will check the yplus then it will consider the appropriate value (omegavis or omegalog), for this you better read the thread "compressible k omega SST" there are some insight on how the model was implemented by the user henry. Edit: I'll check the source code too.

 March 5, 2014, 06:20 #6 Member   Manan Join Date: Oct 2013 Location: Göteborg Posts: 37 Rep Power: 5 Do you know the name/tag/webpage of the developer who implemented kOmegaSST? Would like to have a look at his comments because the kOmegaSST.H file does not specify any wall functions for nut as such! :!

 March 5, 2014, 06:58 #7 Senior Member   ArathoN Join Date: Jul 2011 Posts: 137 Rep Power: 8 here the thread : http://www.cfd-online.com/Forums/ope...komegasst.html And the developer is henry, if you read all the thread you'll see how he advice to use the nutUspalding as a WF for the komegasst and when i tried it i had better results, with calculated it underestimated the dissipation effects. By the way now that i'm reading your BCs they are very strange: First you imposed the pressure at inlet and outlet and you set that the velocity gradient must be zero there so it should be a fully developed flow in both patches, but in this case the variation of the pressure must be congruent with the dissipation ratio of the pressure otherwise the results will be really weird, it's better to set: inlet: U fixed value / p zerogradient outlet: U zerogradient / p fixed value 0 with these you'll have the region whre the flow will develop, then the fully developed flw so the length must be appropriate (it depends if the flow is laminar or turbulent). Second you said you are using the cyclic BCs but i see no cyclyc type in you BCs, in you have connected the inlet with the outlet in blockmeshDict you need to set every variable as type cyclic in the patches inlet and outlet, otherwise OF will not recognize the cyclic condition and will switch to the default settings, like this Code: boundaryField { inlet { type cyclic; } outlet { type cyclic; } fixedWalls { type nutUSpaldingWallFunction; } frontAndBack { type empty; } middle { type symmetryPlane; } } Third what solver are you using? remember that simplefoam doesn't work well with the cyclic condition, in this case you better use the mappedpatch condition (this like the cyclic it will map the result of the desired patch to the target patch so u can map the values at the outlet to the inlet) or install the 1.6_extent version where there is the channalFoam solver now incorporated into pimpleFoam. Forth even the BCs for k and omega are wrong, the problem as you stated is ill conditioned, you didn't give any initial value to these fields, change the inlet condition to fixed value where you compute the values by the known relations of k and omega (see this wiki page http://www.cfd-online.com/Wiki/Turbu...ary_conditions and take the relations with the mixing length or see the code and you'll find their expressions). And the value of Omega at the wall is given by this relation \omega_{wall} = 10 \frac{6 \nu}{\beta_1 (\Delta d_1)^2} where d1 is the distance of the first node to the wall.

March 5, 2014, 15:22
#8
Member

Manan
Join Date: Oct 2013
Location: Göteborg
Posts: 37
Rep Power: 5
Hi ArathoN

I initially set off with exploring channel flow. I assumed that since the flow would be developed, d/dx of all fields other than pressure would be zero. That is why I enforced a fixedValue for pressure at the inlet and outlet to create a pressure gradient, but kept the other quantities as zeroGradient at those patches.

On further thought, I suppose that a cyclic boundary condition is what might be more suited for channel flow. (Especially since one doesn't know before hand, if the flow is developed) However, declaring the inlet and outlet as neighboring cyclic patches does not allow me to have separate values for pressure at the inlet and the outlet.

Are you aware of some strategy to enfore a cyclic condition on ONLY a few fields and not all? In this case, for example, I would like to keep pressure as fixedValue at the inlet and outlet, but other fields as cyclic.

Quote:
 Third what solver are you using? remember that simplefoam doesn't work well with the cyclic condition, in this case you better use the mappedpatch condition (this like the cyclic it will map the result of the desired patch to the target patch so u can map the values at the outlet to the inlet) or install the 1.6_extent version where there is the channalFoam solver now incorporated into pimpleFoam.
I am using simpleFoam and was not aware of its problems with cyclic condition. Regarding the usage of mapped Patch, I run into the same problem again: it maps, say the inlet to the outlet patch for all fields, which is not what I would like to have. (I must have a pressure gradient !)

What do you think?

March 5, 2014, 16:07
#9
Member

Manan
Join Date: Oct 2013
Location: Göteborg
Posts: 37
Rep Power: 5
Quote:
 Fourth, even the BCs for k and omega are wrong, the problem as you stated is ill conditioned, you didn't give any initial value to these fields, change the inlet condition to fixed value where you compute the values by the known relations of k and omega
I have enforced Neumann conditions here (gradient is 0), so the problem is not ill-conditioned. Don't you think so?

But even if I were to declare the patches as cyclic, then also it should be okay, because the solver gets more equations by the relation between the cyclic patches and the number of variables is still equal to the number of equations. I think!

 March 8, 2014, 10:07 #10 Senior Member   Huang Xianbei Join Date: Sep 2013 Location: CAU,China Posts: 277 Rep Power: 6 Hello,MaLa I'm not sure why nu=1/395, for me this number is quiet large because in my case,Ret=194, the nu=1e-6(the fluid is water), so what kind of fluid are you focusing on? I'm doing channel calculation too, while the results are poor. I use DNS, the process of the flow being quasi-steady turbulent is time consuming

 March 10, 2014, 03:25 #11 Member   Manan Join Date: Oct 2013 Location: Göteborg Posts: 37 Rep Power: 5 Hello huangxianbei, I assumed nu =1/395 for an imaginary fluid. I wanted to achieve a Reynolds_tau =395, so by chosing the dimensions of the channel in such a way that u_tau (wall shear velocity) = 1 and y_0.5 (half channel width) = 1, leads to setting nu =1/395. (Re_tau = u_tau * y_0.5 / nu). Do you think this approach is ok?

March 10, 2014, 03:42
#12
Senior Member

Huang Xianbei
Join Date: Sep 2013
Location: CAU,China
Posts: 277
Rep Power: 6
Quote:
 Originally Posted by MaLa Hello huangxianbei, I assumed nu =1/395 for an imaginary fluid. I wanted to achieve a Reynolds_tau =395, so by chosing the dimensions of the channel in such a way that u_tau (wall shear velocity) = 1 and y_0.5 (half channel width) = 1, leads to setting nu =1/395. (Re_tau = u_tau * y_0.5 / nu). Do you think this approach is ok?
In theory domain, I think it's ok to do such a imagination. I'm just interested in the fluid whose nu=1/395,for I haven't got to known this kind of fluid.

By the way, I'd like to ask a question about the distribution of Ux(mean) in the y direction. In my result, the profile is not so smooth (some tiny drops of value somewhere), is your profile looks good?

 March 10, 2014, 03:50 #13 Senior Member   Huang Xianbei Join Date: Sep 2013 Location: CAU,China Posts: 277 Rep Power: 6 look at this picture, you can see obviously that the curve is not smooth

 March 10, 2014, 04:19 #14 Senior Member   ArathoN Join Date: Jul 2011 Posts: 137 Rep Power: 8 Mmmmmm what value of the velocity did you set in the inlet? Because you need to correlate properly U_inf with u_tau. The relation if I remember correctly is U_inf/u_tau=√(2/Cf). So you have to evaluate the Cf of your case then you can calculate u_tau, particularly OF has an utility to calculate the wallshearstress and from there you'll have u_tau.

 March 10, 2014, 04:33 #15 Senior Member   Huang Xianbei Join Date: Sep 2013 Location: CAU,China Posts: 277 Rep Power: 6 Well, I just run the channel395 tutorial to see if everything goes well. There are no inlet and outlet, using periodic in the x direction instead. And a perturbation is generated to make the flow goes turbulent quickly. When the streamwise velocity oscillating around the Ubar, the flow is supposed to be statical turbulent.(I'm wondering there should be a more accurate method to judge when it reaches this situation, how do you judge this situation in your simulation?)

 June 19, 2014, 04:48 #16 Senior Member   sivakumar selvaraju Join Date: Mar 2009 Location: Cape Town - South Africa Posts: 186 Rep Power: 9 Hi There, I think you all are more clear about KOmegaSST wall treatment for low Re case. In my case the y+ is 3 to 5, So I am planning to use the following setup for KOmegaSST (low Re): for K: inlet { type fixedValue; value uniform 0.39; } outlet { type zeroGradient; } top0 //Wall { type fixedValue; value uniform 1e-10; } Omega: inlet { type fixedValue; value uniform 0.99; } outlet { type zeroGradient; } top0 //Wall { type omegaWallFunction; value uniform 0.99; // ??????? } nut: inlet { type calculated; value uniform 0; } outlet { type calculated; value uniform 0; } top0 // Wall { type nutUSpladingWallFunction; Or fixedValue? value uniform 0; } Please give me your suggestions, Thanks, Sivakumar

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post skuznet OpenFOAM Pre-Processing 3 December 1, 2013 23:54 dancfd OpenFOAM Pre-Processing 0 June 9, 2011 23:25 ash-khan FLUENT 0 June 21, 2009 10:02 Hui Main CFD Forum 2 July 25, 2008 23:28 R.D.Prabhu Main CFD Forum 0 July 17, 1998 17:23

All times are GMT -4. The time now is 20:36.