[itchy]

Hi Peter,

yes I mean "compute the coefficients as local average of their face values". That's a kind of smoothing or better filtering of the coefficient. Pherhaps its better to clip cD instead of nuSgs, but both is possible. In my opinion local average can be bad near the wall, but usually it should work as well. if it is stable for your case, don't do the local average of the Smagorinsky-parameter.

You said, that for your case the most people use the dynamic Smagorinsky model in literature. So it should work.

Is your grid fine enough for LES?? You have to check y+ and measure the turbulence resolution. An easy way for measuring the turbulence resolution Res_turb is for example:

Res_turb = <k_Sgs> / (K+<k_Sgs>)

here <k_Sgs> is the mean value of k_Sgs over time and K=0.5*(UPrime2Mean_xx + UPrime2Mean_yy + UPrime2Mean_zz). The value of Res_turb should be smaller than 0.2 over the whole domain.

If you have checked all of this and everything is right, pherhaps your problem is in the formulation of your heatflux?? Please check this:
"Large-Eddy Simulations and heat-flux Modeling in a turbulent impingning Jet" Uddin, Neumann, Weigand, Younis

This could also be the reason why the local heat transfer coefficient at the wall is under predicted.

kind regards
Florian

[palmerlee]

Hi, Florian!

Thank you for your reply! I've checked the mesh. For the coarse mesh, y+ < 2.4 and for the finer one, y+ < 1.2. But the results are almost the same for those two mesh.

Then, I checked the Res_turb, which is smaller than 0.2 in most of the area. In the small domain very close to the inlet boundary, Res_turb is 1. I guess it's because the inlet boundary has no turbulence (I don't know how to add turbulence at the boundary using groovyBC) and the nuSgs is set to zeroGradient. Should I set nuSgs to zero at this boundary? It is almost the same situation at the wall boundary. So, should I set nuSgs to zero at the wall?

I'll try to shut down the local average of the Smagorinsky-parameter.

Sorry for my poor English!

Kind regards
Peter

[itchy]

Hi Peter,

sorry for the late reply.

If you use zeroGradient for nuSgs at the wall your y+ should be smaller 1. Pherhaps smaller 0.5 Don't set nuSgs=0 at the wall for your case.

In your case I would use a wallfunction. Do it like this:

Peterwall
{
type nuSgsWallFunction;
value uniform 1e-10;
}

the value is only a placeholder, you need to set it, but the amoung of the value does not matter.

Or your grid has to be finer at the wall. If y+ is smaller 0.5 use nuSgs=zeroGradient.

You do not need groovyBC to setup a turbulent bc. You need a inflow-generator. Then you can interpolate the values to the domain or to the boundary. Depends on the case setup. For a domain with cyclic bc you have to set the turbulence in the domain. For a case with "normal" bc you have to set the turbulence at the baoundary.

kind regards
Florian

[palmerlee]

Hi, Florian!

Thank you for your reply! I've found the problem. It is the inflow boundary. The turbulence at the inflow boundary in my simulation was so small that the results only match those orifice nozzle cases but not the long pipe case in the literature. Therefore, as you suggest, I should simulate the long pipe first, and then interpolate the values to the inflow boundary.

Kind regards
Peter

[itchy]

Hi Peter,

if you simulate a long pipe it depends on your mesh if you get turbulence or not (with a bad or coarse mesh you get turbulence, with a fine mesh not). In theory if you don't initialize the velocity field with turbulence you get a laminar solution, even if Re>>2300.

so you should use a inflowgenerator or the setFields function with a shearing inital velocity field.

kind regards
Florian

[palmerlee]

Originally Posted by itchy

Hi Peter,

if you simulate a long pipe it depends on your mesh if you get turbulence or not (with a bad or coarse mesh you get turbulence, with a fine mesh not). In theory if you don't initialize the velocity field with turbulence you get a laminar solution, even if Re>>2300.

so you should use a inflowgenerator or the setFields function with a shearing inital velocity field.

kind regards
Florian

Hi, Florian!

Thank you for your prompt reply!

Forgive me if my question sounds silly, but I want to make sure. Do you mean I should use an inflow generator for the long pipe simulation or I should use an inflow generator instead of the long pipe simulation?

Kind regards
Peter

[itchy]

Hi Peter,

I'm not sure but you only have to simulate a long pipe if your inflow-conditions are timedependent. Then you need a inflowgenerator for the pipe. If you get turbulence without a inflowgenerator in the pipe, then your mesh is not good enought.

If your flowrate is constant, an easy way could be:

1) make a pipe with length 5*diameter
2) for inlet and outlet use cyclic boundary conditions
3) use pressureGradientExplicitSource in /system/fvOptions
4) Use setFields function to initialyze a "proper" initial field for example smth. like this:
=====================
---> ---> --->
-------> -------> ------->
---> ---> --->
=====================
Don't use a profile!!! smth like a jet in the middle.

With this velocity field you get very fast turbulence.
4') or you initialyze it with a inflowgenerator or perturb
5) solve the problem that the flow goes 4-10 times through the domain
6) extract the profiles in the middle
7) map the profiles to your impinging jet geoemtry for the right timesteps

I checked this method for a pipe and it works well in my case.

kind regards
Florian

[palmerlee]

Hi, Florian!

Thank you for your instruction! I believe it helps me and many other CFDers. Still, I have one more question to figure out:

6) extract the profiles in the middle
7) map the profiles to your impinging jet geoemtry for the right timesteps

To extract the data in a period (5 seconds, for instance) so that the velocity at the impinging jet inflow boundary has fluctuations (changes its values as time passes), right?

Kind regards
Peter

[itchy]

Hi Peter,

that's right. You need fluctuations at the inlet of the pipe in the impinging jet simulation. In my opinion for this geometry the inletconditions (especially the fluctuations) are very important.

The best way to get proper inletvalues for impinging jet is to do a simulation of pipe (cyclic 5*D length) and map the velocityfield (including the fluctuations) to your impinging jetpipe.

You don't have to map the profiles for every timestep. It should be ok if you use timevarying inletcondition and interpolate the profiles of your pipe simulation.

Another problem is to get good results of the pipesimulation. I think it is not so easy to get good values of the pipe simulation (it looks easy, but it is not!). The grid has to be very fine near the wall (three cells y+<1) if you use dynamic Smagorinsky. Or you can use wallfunctions if y+ isn't small enough. Or damping like VanDriest. There are so many possibilities.

A fact about pipeflow:
In theory, in a perfect world with a perfect pipe there is no turbulence!. So you have to init the turbulence in the pipe. In some books you can find, that the pipeflow is turbulent if Re>2300. That's not true. It depends on your pipe, the inletconditions and all the other conditions. Some people get laminar pipeflow with Re=40000.

kind regards
Florian

[palmerlee]

Hi, Folrian!

Thanks a lot for those knowledge! I've learned a lot from your last post and all the previous posts. And I'm sure they are helpful to others too.

I hope the implementation of mapping or interpolating in OpenFOAM is not very hard.

Kind regards
Peter

[itchy]

Hi Peter,

for interpolation and "mapping" the data have a look at tutorial:
/run/tutorials/simpleFoam/pitzDailyExptInlet.

Which boundary condition do you use at the moment for the inlet?? turbulentIntlet??

I made some simulations with a impinging jet. Geoemetry and boundary-conditions of:
Naseem Uddin et al. Large-Eddy simulations and heat-flux modelling in aturbulent impinging jet.
I have some problems with the outlet. After some timesteps a vortex enters the outlet and my simulation crashs. What kind of boundary-conditions do you use for the outlet???

kind regards
Florian

[palmerlee]

Hi, Folrian!

0/U file:

inlet
{
type groovyBC;
value uniform (0 0 -9.93);
variables
(
"umax=9.93/0.791;"
"R=0.0035;"
"r=sqrt(sqr(pos().x)+sqr(pos().y));"
"u=umax*pow((1.0-r/R), (1.0/6.0));"
);
valueExpression "vector(0,0,-u)";
}

outlet
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}

0/p_rgh file:

inlet
{
type zeroGradient;
}

outlet
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rhok;
psi none;
gamma 1;
value uniform 0;
}

The p_rgh to my solver is p to other solvers. You can find details of this type of outlet boundary condition in section 2.3.2 of UserGuide of OpenFOAM.

Kind regards
Peter

[itchy]

Hi Peter,

thx for the fast reply.

my boundary conditions are very similar.

----------0/U----------------
inlet:
fixedValue (I will change that later to timeVaryingMappedFixedValue with the profiles of the pipe simulation)

outlet:
pressureInletOutletVelocity;
uniform (0 0 0);

----------0/p---------------
inlet:
zeroGradient

outlet:
fixedMean;
meanValue 0.0;
uniform 0.0;

I think that is nearly the same

At the beginning the simulation runs very well. The simulation crashs, when the "start-up eddy" enters the outlet.

Do you initialyse the domain with some velocity radial to the impinging-wall? I will do that, perhaps the large eddy will not develope.

For your inlet you can also use "turbulentInlet" instead of inflowgenerator or mapping. I also will test this.

kind regards
Florian

[itchy]

hi again,

i will check the totalpressure condition for my case like you did it for your case.

kind regards
Florian

[palmerlee]

Hi, Folrian!

Do you initialyse the domain with some velocity radial to the impinging-wall?

No, I didn't. I guess totalPressure will work for your case.

For your inlet you can also use "turbulentInlet" instead of inflowgenerator or mapping.

I still haven't figured out how to use both turbulentInlet and non uniform velocity (distribution set by groovyBC) at the same time. Perhaps you can give me some hits?

Kind regards
Peter

[itchy]

Hi Peter,

I will test the turbulentinlet with nonuniform velocity profile. I let you know if I can handle this.

kind regards
Florian

[itchy]

Hi Peter,

thx the new boundary-condition works.

I have done some simulation of a pipe and mapped velocity profiles to the inlet (using TimeVaryingMappedFixedValue). This works, but I need a lot of inputdata, that the pipe gives good results. The problem is, that this method is not easy to handle, because of the huge amount on inputdata. I will write a script (smth like the sample utility), that export the velocity etc. data and convert the data to the inputformat + folderstructure of TimeVaryingMappedFixedValue. I let you know if this works.

kind regtards
Florian

[itchy]

Hi Peter,

concerning the mapping method, I wrote an addin to the pimpleFoam solver (see attached). This solver writes each runTime++ the velocityfield of a boundary (for example inlet) in a folder called boundaryData. The structur is exactly the format you need for TimeVaryingMappedFixedValue boundary condition. You only have to copy the folder boundaryData from the pipe-Simulation to the simulation of the impingjet. Then you get the right inletvalues with turbulence and profile. You can control the solver by a dictionary calling MAPPING in the fvSolution.

I attached you the Solver and the fvSolution.

Next step is testing this procedure.

After that, I want to write a Turbulencegenerator.

How is it going with the turbulentinlet including profile???

kind regards
Florian

[itchy]

hi,

here is the command for the fvSolution (place it at the end of fvSolution) :

MAPPING
{
mapStartTime 2.9;
mapEndTime 3.0;
mapWriteStartTime 0.0;
boundaryName inlet;
}

kind regards
Florian

[itchy]

Hi,

the solver does not work in parallel.

kind regards
Florian