CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Pre-Processing (http://www.cfd-online.com/Forums/openfoam-pre-processing/)
-   -   How to set up BCs for k epsilon model (http://www.cfd-online.com/Forums/openfoam-pre-processing/64634-how-set-up-bcs-k-epsilon-model.html)

Julian K. May 18, 2009 05:00

How to set up BCs for k epsilon model
 
Hi,

I started to use OpenFOAM 2 weeks ago and as an exercise I would like to simulate the "elbow"-tutorial of Fluent's tutorial guide.
http://193.204.76.120/fluent6.2/help/html/tg/node12.htm

I set up the BCs for U and p, however I do not know how to define the BCs for k and epsilon. First of all, I calculated k according to

k = 1/2 * (u'_x + u'_y + u'_z)

Since the elbow geometry has 2 inlets, I calculated two k, one for each inlet:

k_1 = 0.02 m s
k_2 = 0.5 m s


Now, I'd like to set the k file in the /0 directory. However, I don't know which patch field types I shoud use for the different patches. Should I use 'fixedValue' at the inlets and set the internal field to uniform 0 ? At the walls and the outlet I'd then apply a 'zeroGradient'.

I calculated epsilon to be

eps_1 = 0.01641 m s
eps_2 = 2.05122 m s


for the two inlets.
Here I though of using 'fixedValue' at the inlets, 'zeroGradient' at the walls and the outlet and setting the internal field uniformly to a value between eps_1 and eps_2, for instance to 1.

Was my choice okay, or do you have any suggestions?


Bye,

Julian

wolle1982 May 18, 2009 09:20

Hi and welcome to the daily fight against the elements (of OpenFOAM),

the BC should be
inlet:
U: fixed value
p: zero gradient
k/eps/omega: value

outlet:
U: zero ngradient
p: fixed value (0)
k/eps/omega: zero gradient

walls:
U: fixed value
p: zero gradient
k/eps/omega: zero gradient
the internal field value you can set the same as the inlet value, sometimes it helps starting the calculation. but mostly it seems to be so unimportant.

Anyway it will be overwritten after the first timestep.

The values for epsilon and k also seem to be uninteresting. just give a k intensity and it will calculate its values itself.

Julian K. May 18, 2009 11:32

Hi,

thank you very much for the answer!

Just another short (greenhorn) question:
In which file do I have to define the 'k intensity' (by 'k intensity' you mean 'turbulence intensity', don't you)?
In case I define just the 'k intensity', will I have to initialise the internal field for k/epsilon with 0 and set the patch types to 'zeroGradient'.


cheers,

Julian

olesen May 19, 2009 05:00

Quote:

Originally Posted by Julian K. (Post 216534)
In which file do I have to define the 'k intensity' (by 'k intensity' you mean 'turbulence intensity', don't you)?
In case I define just the 'k intensity', will I have to initialise the internal field for k/epsilon with 0 and set the patch types to 'zeroGradient'.

I generally use settings similar to what you find in the tutorials/compressible/rhoPorousSimpleFoam/angledDuctImplicit/0/
inlet:
U
: flowRateInletVelocity
p: zeroGradient
k: turbulentIntensityKineticEnergyInlet
epsilon: turbulentMixingLengthDissipationRateInlet
omega: turbulentMixingLengthFrequencyInlet

outlet:
U: inletOutlet
p: fixedValue
k/epsilon/omega: inletOutlet

It is 'mostly' irrevelant which values you take for the initial k/epsilon/omega fields, but initializing with zero for things like epsilon is likely to be a bad idea (== no dissipation and/or divide-by-zero problems).

Using an inletOutlet for the outlets also seems to be a good idea. It works the same as a normal outflow, but if the flow happens to reverse, you have a defined boundary condition.

Remeber that the pressure is NOT relative in compresssible cases (ie, zero would be really bad idea). After making a transcription error once (Pa vs. bar), I always use the OpenFOAM dictionary expansion function. For example in 0/p:

internalField uniform 1.0e5;
boundaryField
{
...
outlet
{
type fixedValue;
value $internalField;
}
}


/mark

juanma February 2, 2010 05:27

Quote:

Originally Posted by olesen (Post 216581)
I generally use settings similar to what you find in the tutorials/compressible/rhoPorousSimpleFoam/angledDuctImplicit/0/
inlet:
U
: flowRateInletVelocity
p: zeroGradient
k: turbulentIntensityKineticEnergyInlet
epsilon: turbulentMixingLengthDissipationRateInlet
omega: turbulentMixingLengthFrequencyInlet

outlet:
U: inletOutlet
p: fixedValue
k/epsilon/omega: inletOutlet

It is 'mostly' irrevelant which values you take for the initial k/epsilon/omega fields, but initializing with zero for things like epsilon is likely to be a bad idea (== no dissipation and/or divide-by-zero problems).

Using an inletOutlet for the outlets also seems to be a good idea. It works the same as a normal outflow, but if the flow happens to reverse, you have a defined boundary condition.

Remeber that the pressure is NOT relative in compresssible cases (ie, zero would be really bad idea). After making a transcription error once (Pa vs. bar), I always use the OpenFOAM dictionary expansion function. For example in 0/p:

internalField uniform 1.0e5;
boundaryField
{
...
outlet
{
type fixedValue;
value $internalField;
}
}


/mark

Dear Olesen

I have a question:
What does "$internalField" means (as a defined value for the outlet)? Does it mean that the value for the surface is the one of the cells that shares with the fluid? Or it takes another value? Thanks a lot

Juanma

olesen February 2, 2010 05:41

Quote:

Originally Posted by juanma (Post 244554)
I have a question:
What does "$internalField" means (as a defined value for the outlet)? Does it mean that the value for the surface is the one of the cells that shares with the fluid? Or it takes another value? Thanks a lot

None of the above. The "$internalField" is simply a dictionary expansion.
In this example,

Code:

internalField  uniform 1.0e5;
boundaryField
{
    ...
    outlet
    {
        type            fixedValue;
        value          $internalField;
    }
}

The "$internalField" would expand to "uniform 1.0e5" (your initialization field itself). At later time steps, the value will be filled in with what OpenFOAM has calculated for the those boundary faces. For most cases it is only needed to ensure that the field is properly initialized and that the post-processing works correctly.

If you are playing about with using the dictionary variables, the utility "expandDictionary" can come in quite handy to verify that your dictionaries are actually getting expanded as desired.

juanma February 3, 2010 03:47

Quote:

Originally Posted by olesen (Post 244558)
None of the above. The "$internalField" is simply a dictionary expansion.
In this example...

The "$internalField" would expand to "uniform 1.0e5" (your initialization field itself). At later time steps, the value will be filled in with what OpenFOAM has calculated for the those boundary faces. For most cases it is only needed to ensure that the field is properly initialized and that the post-processing works correctly.

If you are playing about with using the dictionary variables, the utility "expandDictionary" can come in quite handy to verify that your dictionaries are actually getting expanded as desired.

Thanks for the quick reply!

I understand what you mean but, thinking in the initialization of the case for 0/k and 0/epsilon, if the inlet is defined as fixedValue for these variables, it will maintain the same value for all the iterations and depending on the definition for the others variables (i.e. p as fixedValue and U as zeroGradient) It would be better not to set the the turbulent variables as "fixedValue" but as "calculated". Is that true? Is there any problem to initialize k and epsilon as calculated at the inlet? Thanks again.

Juanma

olesen February 3, 2010 03:57

Quote:

Originally Posted by juanma (Post 244725)
Thanks for the quick reply!

I understand what you mean but, thinking in the initialization of the case for 0/k and 0/epsilon, if the inlet is defined as fixedValue for these variables, it will maintain the same value for all the iterations and depending on the definition for the others variables (i.e. p as fixedValue and U as zeroGradient) It would be better not to set the the turbulent variables as "fixedValue" but as "calculated". Is that true? Is there any problem to initialize k and epsilon as calculated at the inlet? Thanks again.

But k/epsilon aren't 'calculated' at the inlet boundary. If you do this, your equations will be underspecified. Specifying the turbulent intensity and mixing length with the respective boundary condition types makes more sense. They'll need a'value' entry though (as previously described) to have properly initialized fields for the time 0.

nileshjrane August 27, 2010 05:50

hello All,
What would be better choice for specifying turbulence parameters??? "fixedValue" or "calculated through turbulent intensity and mixing length like turbulentIntensityKineticEnergyInletlike" ???

I suppose this should not matter as far as i am giving same BC for k and eps and omega etc.

maysmech September 8, 2010 18:15

Quote:

Originally Posted by nileshjrane (Post 273044)
hello All,
What would be better choice for specifying turbulence parameters??? "fixedValue" or "calculated through turbulent intensity and mixing length like turbulentIntensityKineticEnergyInletlike" ???

i have same problem.
please tell me how and where can i define turbulent intensity ( i want 5%) for inlet velocity.
Regards.

nileshjrane September 9, 2010 03:08

Put this in "/0/k" file for inlet. 0.05 corresponds to 5%. The value is actual value of k that you can calculate from 5% Turb intensity. I am not sure whether it is significant or nor, but i think its better to use appropriate value nevertheless.

Code:

    inlet
    {
        type            turbulentIntensityKineticEnergyInlet;
        intensity      0.05;
        value          uniform 60;
    }


maysmech September 9, 2010 03:53

Quote:

Originally Posted by nileshjrane (Post 274546)
Put this in "/0/k" file for inlet. 0.05 corresponds to 5%. The value is actual value of k that you can calculate from 5% Turb intensity. I am not sure whether it is significant or nor, but i think its better to use appropriate value nevertheless.

Code:

    inlet
    {
        type            turbulentIntensityKineticEnergyInlet;
        intensity      0.05;
        value          uniform 60;
    }


Thanks Nilesh,
You mean it is not necessary to define anything in 0/u file. if no, what is the meaning of this phrase? :
Code:

boundaryField
{
    inlet         
    {
        type            turbulentInlet;
        referenceField  uniform (1 0 0);
        fluctuationScale (0.05 .01 0);
        value          uniform (1 0 0);
    }

Best regards.

nileshjrane September 9, 2010 06:31

I have never used turbulentInlet as such, but i am guessing that you specify the turbulence in terms of fluctuating velocity (as in u+u'). I have no idea how exactly this BC works. You can specify turbulence this way as well, no doubt, but i think this is much specific way than giving turbulent intensity, which is approximate guess generally speaking. And if i am not wrong, turbulentInlet is not meant for RANS. It makes sense to use it for LES/DNS. In RANS we always solve equations for mean values and not for fluctuating part of any variable.

Even though you specify turbulence in "/0/u" file, still you need to initialize k and epsilon/omega in respective files. So to me specifying turbulence in k file makes more sense. I can't think of a way for calculating velocity fluctuations for specifying turbulence. How would you know what values to give?? At least i have never seen specifying turbulence with velocity fluctuations.

nileshjrane September 9, 2010 06:40

This is the description of turbulentInlet BC given in source code.

Description
Generate a fluctuating inlet condition by adding a random component
to a reference (mean) field.
Input:
referenceField
Mean field.
fluctuationScale
RMS fluctuation, provided as the fraction of the mean field.
alpha
temporal correlation factor;
the fraction of the new random component added to the previous
time-step (defaults to 0.1).

maysmech September 9, 2010 07:51

Quote:

Originally Posted by nileshjrane (Post 274572)
And if i am not wrong, turbulentInlet is not meant for RANS. It makes sense to use it for LES/DNS. In RANS we always solve equations for mean values and not for fluctuating part of any variable.

Thanks,
as you mentioned turbulentInlet is for LES/DNS. i searched in tut files and not found this inlet type for RAS.
i will add intensity to k and compare results with benchmark.
Best.

Eren10 May 26, 2011 14:07

Quote:

Originally Posted by wolle1982 (Post 216508)
Hi and welcome to the daily fight against the elements (of OpenFOAM),

the BC should be
inlet:
U: fixed value
p: zero gradient
k/eps/omega: value

outlet:
U: zero ngradient
p: fixed value (0)
k/eps/omega: zero gradient

walls:
U: fixed value
p: zero gradient
k/eps/omega: zero gradient
the internal field value you can set the same as the inlet value, sometimes it helps starting the calculation. but mostly it seems to be so unimportant.

Anyway it will be overwritten after the first timestep.

The values for epsilon and k also seem to be uninteresting. just give a k intensity and it will calculate its values itself.


The BC settings are not correct. k-epsilon needs wall treatment. I don't if the other settings are oke !

maysmech May 26, 2011 15:43

Quote:

Originally Posted by Eren10 (Post 309398)
The BC settings are not correct. k-epsilon needs wall treatment. I don't if the other settings are oke !

It depends on your y+.

If your mesh be refined near wall and yPlus value be less than ~5 you don't need to use wallFunction and zeroGradient is the correct choice.

Best,

juanma May 27, 2011 04:49

Quote:

Originally Posted by maysmech (Post 309407)
It depends on your y+.

If your mesh be refined near wall and yPlus value be less than ~5 you don't need to use wallFunction and zeroGradient is the correct choice.

Best,

Hello Maysam,

That's right. Under a certain threshold for y+ the mesh can reproduce reasonably the growth of the boundary layer. BUT, I try to define k and epsilon as a zeroGradient and OF renames my k and epsilon files (as *.org) and writes a new ones with the wallFunctions inside the patch of the wall. Any suggestion?

Thanks in advance,
Juanma

Eren10 May 27, 2011 05:00

I am running k-epsilon model with the simpleFoam solver, but the results are not converging. The initial residual for pressure remains the same after some value, in this case 0.002. :confused:

BC:
U file
inlet freestream value()
outlet zeroGradient
wall fixedValue

p file
inlet freestreamPressure
outlet zeroGradient
wall zeroGradient

k file
inlet fixedValue (20)
outlet zeroGradient
wall kqRWallFunction (20)

epsilon file
inlet fixedValue (50)
outlet zeroGradient
wall epsilonWallfunction (50)

nut file
inlet freestream (0)
outlet zeroGradient
wall nutWallFunction (0)

Can someone point out the wrong BC, please.

Eren10 May 30, 2011 06:16

is there nobody on the forum with k-epsilon-openfoam experience ? :(


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