Paper for boundary condition of turbulence intensity at inlet

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

June 8, 2022, 04:05
Paper for boundary condition of turbulence intensity at inlet
#1
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
I've seen the formula that is written in uploaded picture.
But I'm wondering how this equation is derived.
Also I want to know why this formula can be applied to first iteration only not 2nd and other after progressed iteration.
I think I can find the reason if I read some paper or literature that includes
meaning of this formula or derivation of this formula.
But I couldn't find the first paper that claims this formula.
Can you guys let me know?
Thanks
Attached Images
 20220608_160043.png (4.3 KB, 11 views)

 June 8, 2022, 12:14 #2 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 The first comes from the definition of k and turbulence intensity plus the assumption that |u'|=|v'|=|w'|, which results in that form for k. The latter is simply the definition of turbulent length scale in the k-epsilon turbulence model, re-written with epsilon on the left hand side. Neither of these actually give you any boundary conditions, they simply are formulas for manipulating info at the inlet that you might have from one form into another. You still need to know the turbulence intensity and turbulence length scale to do anything. I don't follow the latter part of the question. Boundary conditions are boundary conditions, they are applied all the time regardless of iteration. You're likely confusing how these formulas are employed in estimating boundary conditions at inlets versus coming up with an initial guess for the flow solution to start the CFD, or both. FluidKo likes this.

June 8, 2022, 22:59
#3
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran The first comes from the definition of k and turbulence intensity plus the assumption that |u'|=|v'|=|w'|, which results in that form for k. The latter is simply the definition of turbulent length scale in the k-epsilon turbulence model, re-written with epsilon on the left hand side. Neither of these actually give you any boundary conditions, they simply are formulas for manipulating info at the inlet that you might have from one form into another. You still need to know the turbulence intensity and turbulence length scale to do anything. I don't follow the latter part of the question. Boundary conditions are boundary conditions, they are applied all the time regardless of iteration. You're likely confusing how these formulas are employed in estimating boundary conditions at inlets versus coming up with an initial guess for the flow solution to start the CFD, or both.
The reason I write this question is below.

Using OpenFOAM and ANSYS Fluent, I've generated simulation with k-epsilon model for geometry of uploaded picture1.
(This geometry represents jet impingement in curved pipe flow.
Inlet is on left side.
Notice that because of sudden contraction and expansion region, velocity profile doen's show parabolic profile. Velocity profile is similar to developing flow as picture2.)

And I've mapped velocity field to inlet and set 5%(constant) to turbulence intensity.

By upper fomula, I've thought gradient of velocity and gradient of TKE(k) must show same trend over the area of inlet.
And I've thought this trend must be fixed. It must not change over iteration because it is fixed boundary condition like your answer.

But when I operated simulation, I've seen the result that gradient of velocity and gradient of TKE(k) are similar but slightly different and also they are changed a little bit as iteration is repeated.

What they have answered to me is just upper formula is applied to first iteration only and they don't know why.

So what I've guessed is maybe there will be a little trick in code to let simulation converge and let calculation not to bomb.
Even though that trick is slightly wrong and unreasonable to theory(As we can see from result that is slightly changed over iteration), for convergence and stable calcuation, they may do a trick to code.
It is not 100% right theoretically, but can show similar result with convergence and stable calculation.

What do you think about it?
Attached Images
 picture1.png (53.3 KB, 12 views) picture2.png (9.8 KB, 8 views)

June 9, 2022, 04:32
#5
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
Sorry there was one mistake.
I said there was small change of TKE over iteration but actually there was big change of TKE over iteration and also pattern of velocity distribution and pattern of TKE become totally different as iteration is repeated.

From uploaded picture, we can see pattern of TKE for first iteration is similar to pattern of mapped velocity.
But since second iteration, pattern of TKE becomes rapidly different to pattern of mapped velocity.

What is the problem?
Attached Images
 TKE distribution for first iteration.jpg (29.1 KB, 17 views) TKE distribution for second iteration.jpg (30.0 KB, 16 views) TKE boudnary condition option in Fluent.png (16.2 KB, 12 views) Mapped velocity.png (51.3 KB, 13 views)

 June 9, 2022, 13:35 #6 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 There is no problem. You just don't understand what is happening yet. Where even is this plot and what is even being plotted? Is this the "inlet" plotting face values on the inlet faces or is this the cell values of cells adjacent to the inlet? Or is this some other random place? Also plot the same values along a mid-plane slice through the flow, it'll help you visualize what is happening. The picture of tke in the first iteration is also just wrong. tke profiles should never look like that. I'm glad it changed because it looks way better in the 2nd iteration. FluidKo likes this.

June 9, 2022, 23:58
#7
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran There is no problem. You just don't understand what is happening yet. Where even is this plot and what is even being plotted? Is this the "inlet" plotting face values on the inlet faces or is this the cell values of cells adjacent to the inlet? Or is this some other random place? Also plot the same values along a mid-plane slice through the flow, it'll help you visualize what is happening. The picture of tke in the first iteration is also just wrong. tke profiles should never look like that. I'm glad it changed because it looks way better in the 2nd iteration.
These pictures are representating inlet not adjacent to inlet.
I've thought TKE at inlet(not adjacent to inlet) must be fixed because it is boundary.
Pattern of TKE distribution is following pattern of velocity distribution by formula(uploaded picture, TKE boundary condition at inlet, TKE at inlet is not fuction of iteration)
By the way distribution of TKE at inlet(not adjacent to inlet) is changed over iteration.
How it can be changed over iteration?
Attached Images
 20220608_160043 (1).png (4.3 KB, 4 views)

 June 10, 2022, 08:50 #8 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 If you are using OpenFOAM, you'll be using fixedValues typee BC and can just see directly in the files of k and epsilon what are their values at the boundary and we shouldn't have any doubts at all what is happening. If you are using Fluent and make a contour plot and choose a boundary, you are plotting the values interpolated from the inlet faces onto the cell centers, so these are actually boundary adjacent values contrary to what you might think. Also that formula you have for epsilon is not the correct one. You are using the turbulence viscosity ratio method which uses a formula not involving the turbulent length scale. See for example Eqn 7.3-6. It's the same idea but saves us from having a discussion of what is a turbulent length scale. What you could do is generate a plot of the velocity the same way and you for k and see how it changes with iteration. Yet another thing you can do is choose k and epsilon as the specification method and directly put in values for k and epsilon to help improve your understanding. And I'm assuming you are using a velocity inlet, because otherwise more discussions are needed on what inlet BC type you have. FluidKo likes this.

June 10, 2022, 10:26
#9
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran If you are using OpenFOAM, you'll be using fixedValues typee BC and can just see directly in the files of k and epsilon what are their values at the boundary and we shouldn't have any doubts at all what is happening. If you are using Fluent and make a contour plot and choose a boundary, you are plotting the values interpolated from the inlet faces onto the cell centers, so these are actually boundary adjacent values contrary to what you might think. Also that formula you have for epsilon is not the correct one. You are using the turbulence viscosity ratio method which uses a formula not involving the turbulent length scale. See for example Eqn 7.3-6. It's the same idea but saves us from having a discussion of what is a turbulent length scale. What you could do is generate a plot of the velocity the same way and you for k and see how it changes with iteration. Yet another thing you can do is choose k and epsilon as the specification method and directly put in values for k and epsilon to help improve your understanding. And I'm assuming you are using a velocity inlet, because otherwise more discussions are needed on what inlet BC type you have.
Yes you are right.

If you see uploaded 2 pictures with pipe, you can find one thing is whole geometry but another is part of geometry.

Because it spends too much time to generate simulation for whole geometry, we want to map velocity field of mid-slice in whole geometry into inlet velocity field in part of geometry.
And by using upper formulation, we want to set boundary condition of TKE to inlet then we want to capture accurate TKE field in part of geometry as TKE filed in whole geometry.

We've generated simulation using OpenFOAM also.
But OpenFOAM also shows similar result to Fluent.
I can understand your meaning that result of Fluent which we can see from uploaded picture is proper.
Because Fluent shows center of the cell not boundary of the cell(Control surface of mesh), what we are seeing must be changed over iteration.
Values for center of the cell must be changed over iteration by interpolation.

But what about result of OpenFOAM?
Although OpenFOAM shows result at boundary of cell(Control surface of mesh), the result is changed over iteration.

But what I'm guessing is that I'm not sure whether what we have seen is really boundary of cell or center of cell.
Because we are newbie of OpenFOAM...
Also I don't have picture of result in OpenFOAM now.
Another member in our laboratory has it.

So I'm going to receive that picture and check whether what we have seen is boundar of cell or center of cell.
Then I'm going to write question again.
If that time comes, would you do me a favor again?

Attached Images
 20220610_222718.png (32.7 KB, 12 views) 20220610_222728.png (21.5 KB, 11 views)

 June 10, 2022, 10:32 #10 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 I didn't realize you were mapping from one simulation to another. These formulas are for guessing what is the inlet k and epsilon when you have no clue what it should be (i.e. you put in random values for turbulence intensity and viscosity ratio). Since you are mapping the solved velocity field, map also the k and epsilon. Then these formula are not applicable at all. In OpenFOAM you will have something like this in your k and epsilon files: Code: boundaryField { inlet { type fixedValue; value nonuniform List; numberoffaces ( a big freakin list ) } } You (or your colleague who is doing the OpenFOAM simulation) supply this list and that list will never change. If you see anything different then it is a plotting problem because you can physically see with your eyeballs the numbers in this list. If you use fixedValues (and you should) then the solver never modifies that list. FluidKo likes this.

June 11, 2022, 02:02
#11
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran I didn't realize you were mapping from one simulation to another. These formulas are for guessing what is the inlet k and epsilon when you have no clue what it should be (i.e. you put in random values for turbulence intensity and viscosity ratio). Since you are mapping the solved velocity field, map also the k and epsilon. Then these formula are not applicable at all. In OpenFOAM you will have something like this in your k and epsilon files: Code: boundaryField { inlet { type fixedValue; value nonuniform List; numberoffaces ( a big freakin list ) } } You (or your colleague who is doing the OpenFOAM simulation) supply this list and that list will never change. If you see anything different then it is a plotting problem because you can physically see with your eyeballs the numbers in this list. If you use fixedValues (and you should) then the solver never modifies that list.

I should have talked some content of this research to you.

I agree to you.
If I use upper formulas and see result at boundary(not center of cell), I think value(velocity, TKE) must not change over iteration.

I'm going to ask him to confirm which code he is using and whether there is a problem of plotting
Then, I'm going to let you hear about following.

Last edited by FluidKo; July 5, 2022 at 01:25.

June 14, 2022, 01:44
#12
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran I didn't realize you were mapping from one simulation to another. These formulas are for guessing what is the inlet k and epsilon when you have no clue what it should be (i.e. you put in random values for turbulence intensity and viscosity ratio). Since you are mapping the solved velocity field, map also the k and epsilon. Then these formula are not applicable at all. In OpenFOAM you will have something like this in your k and epsilon files: Code: boundaryField { inlet { type fixedValue; value nonuniform List; numberoffaces ( a big freakin list ) } } You (or your colleague who is doing the OpenFOAM simulation) supply this list and that list will never change. If you see anything different then it is a plotting problem because you can physically see with your eyeballs the numbers in this list. If you use fixedValues (and you should) then the solver never modifies that list.
Hello LuckyTran.

I've checked result of OpenFOAM.
I think we have seen the result of boundary(Control surface of mesh) properly,
not center of cell.
But as I told you before, result of boundary is still changed over iteration.

By the way I've heard something intereting to my company.
When he set boundary condition of TKE by using your code(fixedValue),
there is no change of TKE at inlet over iteration.
You can see this from uploaded pictures.
('TKE at inlet for first iteration mapping TKE directly' and 'TKE at inlet for 1030th iteration mapping TKE directly')
* In this picture, k is not obtained by . This is just extracted from TKE field at mid-plane in whole geometry. We set that TKE value into inlet for part of geometry.

But if we set boundary condition of TKE using mapped velocity and constant turbulence intensity by formula in uploaded picture,
('initial value of TKE at inlet using turbulence intensity' and 'TKE at inlet for first iteration using turbulence intensity')
then we can see there is change of TKE at inlet over iteration.
When we use mapped velocity and constant turbulence intensity, we also set epsilon condition by assuming mixing length.
Below are codes that we are using for adapting turbulence intensity to TKE.

Code for k(TKE) condition
Code:
boundaryField
{
inlet
{
type              turbulentIntensityKineticEnergyInlet;
intensity         0.05;
value             $internalField; } outlet { type zeroGradient; } wall { type kqRWallFunction; value$internalField;
}

}
Code for epsilon condition
Code:
boundaryField
{
inlet
{
type              turbulentMixingLengthDissipationRateInlet;
mixingLength      0.000375;
value           $internalField; } outlet { type zeroGradient; } wall { type epsilonWallFunction; value$internalField;
}

}
Code for mapping velocity field
Code:
boundaryField
{
inlet
{
type            timeVaryingMappedFixedValue;
offset          (0 0 0);
setAverage      off;
}

outlet
{
}

wall
{
type            noSlip;
}

}
I want to know why change of TKE at inlet occurs if we use turbulence intensity.
There is no problem when we map TKE directly as you can see from uploaded pictures.
('TKE at inlet for first iteration mapping TKE directly' and 'TKE at inlet for 1030th iteration mapping TKE directly')
But if we use turbulence intesity and mapped velocity to set TKE at inlet boundary,
(Because TKE can be obtained by turbulence intensity and mapped velocity by formula in uploaded picture)
change of TKE at inlet occurs over iteration.
(('initial value of TKE at inlet using turbulence intensity' and 'TKE at inlet for first iteration using turbulence intensity'))
Why it is changed?
How can I explain it and solve it?

Thank you
Attached Images
 Mapped velocity.jpg (65.2 KB, 8 views) TKE at inlet for first iteration mapping TKE directly.jpg (67.2 KB, 7 views) TKE at inlet for 1030th iteration mapping TKE directly.jpg (67.3 KB, 7 views) TKE at inlet for first iteration using turbulence intensity.jpg (61.7 KB, 7 views) TKE at inlet for second iteration using turbulence intensity.jpg (67.0 KB, 7 views)

June 14, 2022, 01:45
#13
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran I didn't realize you were mapping from one simulation to another. These formulas are for guessing what is the inlet k and epsilon when you have no clue what it should be (i.e. you put in random values for turbulence intensity and viscosity ratio). Since you are mapping the solved velocity field, map also the k and epsilon. Then these formula are not applicable at all. In OpenFOAM you will have something like this in your k and epsilon files: Code: boundaryField { inlet { type fixedValue; value nonuniform List; numberoffaces ( a big freakin list ) } } You (or your colleague who is doing the OpenFOAM simulation) supply this list and that list will never change. If you see anything different then it is a plotting problem because you can physically see with your eyeballs the numbers in this list. If you use fixedValues (and you should) then the solver never modifies that list.
Here are more pictures
Attached Images
 TKE at inlet for 50th iteration using turbulence intensity.jpg (59.1 KB, 3 views) TKE at inlet for 99th iteration using turbulence intensity.jpg (60.3 KB, 1 views)

 June 14, 2022, 02:38 #14 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 Code: value $internalField; means it looks at the cell values of the boundary adjacent cells and uses these values for the boundary faces. So if you plot this, you are looking at the interior values according to whatever is in the internalField field and it will be the same no matter what turbulence intensity and what mixing length you apply. So when you plot whatever is in the 0 dir you are looking at the cell values according to whatever is the intiial condition. Then once 1 iteration is performed the boundary values are calculated according to the BC and then updated and properly listed in the boundaryField field. FluidKo likes this. June 14, 2022, 05:35 Sorry... I can't understand yet. #15 Senior Member Sangho Ko Join Date: Oct 2021 Location: South Korea Posts: 133 Rep Power: 3 Quote:  Originally Posted by LuckyTran Code: value$internalField; means it looks at the cell values of the boundary adjacent cells and uses these values for the boundary faces. So if you plot this, you are looking at the interior values according to whatever is in the internalField field and it will be the same no matter what turbulence intensity and what mixing length you apply. So when you plot whatever is in the 0 dir you are looking at the cell values according to whatever is the intiial condition. Then once 1 iteration is performed the boundary values are calculated according to the BC and then updated and properly listed in the boundaryField field.
Sorry...I don't understand some points because I'm not good at both English and CFD.

1. 'uses these values for the boundary faces'
I don't understand why I should use value at adjacent cell to value at boundary surface.
If you see uploaded picture(5 cells), boundary condition for inlet(left side) is 100℃.
We don't use this value to first cell(node 1).
But why we should use value at boundary surface(100℃) to value at adjacent cell(node 1)?

2. 'whatever is in the 0 dir'
What is meaning of 0 direction?
Are you meaning plane with shape of O which represent inlet?
These uploaded pictures are representing boundary surface(Control surface) in Paraview, not adjacent cell(center of control volume).

3. 'whatever is the intial condition'
What is meaning of initial condition?

4. ' then updated and properly listed in the boundaryField field.'
How it is possible to update boundary condition?
I think boundary condition must not change over iteration as you have told me before.
(Boundary conditions are boundary conditions, they are applied all the time regardless of iteration.).

Thank you
Attached Images
 20220614_173903.png (8.4 KB, 3 views)

 June 14, 2022, 10:50 #16 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 If you don't use OpenFOAM, what I've written will make absolutely no sense to you. OpenFOAM data at each iteration or time is stored in directories labeled with numbers. The initial condition is assumed to be 0, if it is not 0 then it is whatever is the starting number. If it is 0, then there is a folder labeled 0 and inside it contains files like p,U,k,epsilon containing all the goodies. Subsequent iterations/time-steps are saved in a folder labeled 1, 2, 3, etc. and each of these will have a bunch of similar files all containing the variables at those states. Whether it is steady of transient, your simulation starts somewhere. The initial condition is wherever you start your simulation, or whatever is in the 0 dir (or whatever dir is the starting dir). An openfoam data file contains two big blocks of important. One called boundaryField which gives values at all the boundary faces. Another called internalField which gives cell values at all the interior cells. 1. The list that you see in values is all the boundary values at this particular state. Normally, there would be a non-uniform list with big list of numbers unless the field is uniform, then there would be a uniform list with just a single number. In this exceptional case, for whatever reason, you and your colleague have decided to use "value $internalField" I didn't do this, you guys did!$internalField is a pointer to the internalField. When you do this, OpenFOAM looks at the interior cell values and uses these values for the boundary faces. According to your example, even though the boundary condition is 100 °C you've told OpenFOAM that the value of the cell face is the value at node 1. When you go to plot this in paraview, instead of plotting 100 °C, it will plot the values at node 1. Why you would do this? I wouldn't! But you did! 2. Whatever is in the 0 dir means whatever is in the 0 directory or whatever is the starting time-step/iteration in this case. Usually you start at 0 just like how you start at iteration 0 or time-step 0. If it is not 0, then it is wherever you started. 3. Whatever is in initial condition means whatever is in the 0 directory. OpenFOAM labels the folders using numbers the same way whether steady state or transient. If you notice in your screenshot of paraview there is a Time 0 1 and 1030 even though it is a steady simulation! This isn't a mistake, that's how OF works. 4. There is a distinction between a boundary condition and a value of a boundary face. Boundary conditions are constraints imposed onto the transport equation by the solver at calculation time. It is permitted that the current value of the boundary faces be different than what is the constraint. Usually it is not a good idea for these to be different for the reasons we are dealing with here. The constraints will be imposed by the solver regardless of what is the list in values but paraview will plot whatever is listed in value. In short, stop using $internalField unless you know what you are doing. Anyway, your understanding that a boundary condition should not change is right. The problem is you don't know how to plot things and when you do, you don't understand what is being plotted. FluidKo likes this. June 14, 2022, 22:00 #17 Senior Member Sangho Ko Join Date: Oct 2021 Location: South Korea Posts: 133 Rep Power: 3 Quote:  Originally Posted by LuckyTran If you don't use OpenFOAM, what I've written will make absolutely no sense to you. OpenFOAM data at each iteration or time is stored in directories labeled with numbers. The initial condition is assumed to be 0, if it is not 0 then it is whatever is the starting number. If it is 0, then there is a folder labeled 0 and inside it contains files like p,U,k,epsilon containing all the goodies. Subsequent iterations/time-steps are saved in a folder labeled 1, 2, 3, etc. and each of these will have a bunch of similar files all containing the variables at those states. Whether it is steady of transient, your simulation starts somewhere. The initial condition is wherever you start your simulation, or whatever is in the 0 dir (or whatever dir is the starting dir). An openfoam data file contains two big blocks of important. One called boundaryField which gives values at all the boundary faces. Another called internalField which gives cell values at all the interior cells. 1. The list that you see in values is all the boundary values at this particular state. Normally, there would be a non-uniform list with big list of numbers unless the field is uniform, then there would be a uniform list with just a single number. In this exceptional case, for whatever reason, you and your colleague have decided to use "value$internalField" I didn't do this, you guys did! $internalField is a pointer to the internalField. When you do this, OpenFOAM looks at the interior cell values and uses these values for the boundary faces. According to your example, even though the boundary condition is 100 °C you've told OpenFOAM that the value of the cell face is the value at node 1. When you go to plot this in paraview, instead of plotting 100 °C, it will plot the values at node 1. Why you would do this? I wouldn't! But you did! 2. Whatever is in the 0 dir means whatever is in the 0 directory or whatever is the starting time-step/iteration in this case. Usually you start at 0 just like how you start at iteration 0 or time-step 0. If it is not 0, then it is wherever you started. 3. Whatever is in initial condition means whatever is in the 0 directory. OpenFOAM labels the folders using numbers the same way whether steady state or transient. If you notice in your screenshot of paraview there is a Time 0 1 and 1030 even though it is a steady simulation! This isn't a mistake, that's how OF works. 4. There is a distinction between a boundary condition and a value of a boundary face. Boundary conditions are constraints imposed onto the transport equation by the solver at calculation time. It is permitted that the current value of the boundary faces be different than what is the constraint. Usually it is not a good idea for these to be different for the reasons we are dealing with here. The constraints will be imposed by the solver regardless of what is the list in values but paraview will plot whatever is listed in value. In short, stop using$internalField unless you know what you are doing. Anyway, your understanding that a boundary condition should not change is right. The problem is you don't know how to plot things and when you do, you don't understand what is being plotted.
Actually I'm newbie of OpenFOAM so I'm not good at code also.
I haven't check the code.
I've missed there is
Code:
value           $internalField; in ours code. Actually this code is written by my company so I couldn't recognize it. I'm sorry that I've asked question before being aware of code. I think this is why I was confused. I'm going to convey your advice to my company and then let you know ours following. Thank you! June 16, 2022, 03:06 Still TKE is changing #18 Senior Member Sangho Ko Join Date: Oct 2021 Location: South Korea Posts: 133 Rep Power: 3 Quote:  Originally Posted by LuckyTran If you don't use OpenFOAM, what I've written will make absolutely no sense to you. OpenFOAM data at each iteration or time is stored in directories labeled with numbers. The initial condition is assumed to be 0, if it is not 0 then it is whatever is the starting number. If it is 0, then there is a folder labeled 0 and inside it contains files like p,U,k,epsilon containing all the goodies. Subsequent iterations/time-steps are saved in a folder labeled 1, 2, 3, etc. and each of these will have a bunch of similar files all containing the variables at those states. Whether it is steady of transient, your simulation starts somewhere. The initial condition is wherever you start your simulation, or whatever is in the 0 dir (or whatever dir is the starting dir). An openfoam data file contains two big blocks of important. One called boundaryField which gives values at all the boundary faces. Another called internalField which gives cell values at all the interior cells. 1. The list that you see in values is all the boundary values at this particular state. Normally, there would be a non-uniform list with big list of numbers unless the field is uniform, then there would be a uniform list with just a single number. In this exceptional case, for whatever reason, you and your colleague have decided to use "value$internalField" I didn't do this, you guys did! $internalField is a pointer to the internalField. When you do this, OpenFOAM looks at the interior cell values and uses these values for the boundary faces. According to your example, even though the boundary condition is 100 °C you've told OpenFOAM that the value of the cell face is the value at node 1. When you go to plot this in paraview, instead of plotting 100 °C, it will plot the values at node 1. Why you would do this? I wouldn't! But you did! 2. Whatever is in the 0 dir means whatever is in the 0 directory or whatever is the starting time-step/iteration in this case. Usually you start at 0 just like how you start at iteration 0 or time-step 0. If it is not 0, then it is wherever you started. 3. Whatever is in initial condition means whatever is in the 0 directory. OpenFOAM labels the folders using numbers the same way whether steady state or transient. If you notice in your screenshot of paraview there is a Time 0 1 and 1030 even though it is a steady simulation! This isn't a mistake, that's how OF works. 4. There is a distinction between a boundary condition and a value of a boundary face. Boundary conditions are constraints imposed onto the transport equation by the solver at calculation time. It is permitted that the current value of the boundary faces be different than what is the constraint. Usually it is not a good idea for these to be different for the reasons we are dealing with here. The constraints will be imposed by the solver regardless of what is the list in values but paraview will plot whatever is listed in value. In short, stop using$internalField unless you know what you are doing. Anyway, your understanding that a boundary condition should not change is right. The problem is you don't know how to plot things and when you do, you don't understand what is being plotted.
Hello. LuckyTran.
Eventhough we've changed code like below, result was same.

Code:
boundaryField
{
inlet
{
type              turbulentIntensityKineticEnergyInlet;
intensity         0.05;
value             uniform 0.055888977;

// Optional entries
U           U;
phi         phi;
}
outlet
{
}
wall
{
type            kqRWallFunction;
value           0;
}

}
We've changed '\$internalField' into 'uniform 0.055888977;'.
But TKE is still changed over iteration.

Actually we've calculated TKE at inlet by below formula.

Then we map this TKE into inlet using 'timeVaryingMappedFixedValue;' module.
This works well so there is no problem now.
Everything is okay.
But we can't understand why TKE is changed over iteration when we adapt module with turbulence intensity('turbulentIntensityKineticEnergyInlet') until now.

 June 16, 2022, 09:48 #19 Senior Member   Lucky Join Date: Apr 2011 Location: Orlando, FL USA Posts: 5,113 Rep Power: 60 You have a non-uniform velocity field, if you use the formula then you can't have a uniform list for k. You're just not calculating k correctly. All you need to do is take the nonuniform list from any subsequent iteration because this one is correctly calculated by OF. Copy and paste that into the 0 dir. FluidKo likes this.

June 16, 2022, 23:19
#20
Senior Member

Sangho Ko
Join Date: Oct 2021
Location: South Korea
Posts: 133
Rep Power: 3
Quote:
 Originally Posted by LuckyTran You have a non-uniform velocity field, if you use the formula then you can't have a uniform list for k. You're just not calculating k correctly. All you need to do is take the nonuniform list from any subsequent iteration because this one is correctly calculated by OF. Copy and paste that into the 0 dir.
I understand that I have to let OpenFOAM know non-uniform velocity field to calculate k corretly by using .
But I can't understand meaning of 'from any subsequent iteration'.
Can I just use velocity field in uploaded picture in this post?
Can I just substitute 'uniform 0.055888977' by velocity field in uploaded picture?
Is iteration necessary?

Thank you
Attached Images
 Mapped velocity.jpg (65.2 KB, 4 views)

 Tags boundary condition, inlet, turbulence intensity