[Julian K.]

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]

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.]

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]

Originally Posted by Julian K.

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]

Originally Posted by olesen

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]

Originally Posted by juanma

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,

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]

Originally Posted by olesen

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]

Originally Posted by juanma

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]

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]

Originally Posted by nileshjrane

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]

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.

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

[maysmech]

Originally Posted by nileshjrane

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.

    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? :

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

Best regards.

[nileshjrane]

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]

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]

Originally Posted by nileshjrane

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]

Originally Posted by wolle1982

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]

Originally Posted by Eren10

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]

Originally Posted by maysmech

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]

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.

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]

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