[DaSh]

Hello fellow-FOAMers,

I am pretty new to using OpenFOAM and doing turbulence modeling itself, but happy to be here. I am looking forward to learn from the massive expertise accumulated in this forum.

Currently I am trying to solve the LES case Channel Flow (Re_tau = 395). It is all based on Channel395 tutorial case. I use a refined mesh with 75x40x96 Nodes (2*Pi*delta x 2*delta x Pi*delta), graded in y-direction. I use the Smagorinsky Model with Van-Driest damping.

Trying to solve the problem without an initial solution (boundary condition) in 0-Folder leaves me with the following (blue is LES, red DNS results from THT-Lab Tokyo).



Thereafter I have tried to generate a initial BC using a RAS-Model until it converged, using its solution as new 0-folder for LES. But the RAS solution was not good and in the end produced similar "solutions" as seen above.

My Questions are actually simple to devise:

1. Is it possible to solve the LES channel flow problem without initial solutions?
2. What boundary conditions do I need for RAS to produce an good initial solution for my LES?

I'd be happy for any help and hints.


Have a good one!

Danesh

Edit: I think the problem of the graph is clear. The near wall velocities are much too small, producing a small u_tau, therefore a small Re_tau, and subsequently leaving me with large u+ ....

[DaSh]

Hello,

anybody has an idea how to run the Channel Flow probem without initial boundary condition?

How do you all create an initial solution for your LES simulations?


If you need further informations about my setup, please let me know.


Thank you all in advance,

Danesh

[Lieven]

Hi Danesh,

Usually you make the boundaries cyclic so that the inlet conditions are being generated on the fly. In openfoam you have the option to use either the 'cyclic' boundary condition or the 'mapped' boundary condition.

What ever you do, don't impose constant (averaged) profiles at the inlet. This is physically just wrong.

Cheers,

Lieven

[DaSh]

Hello Lieven,

thanks for your quick reply. I already use cyclic BC in the 0 folder. For the RAS which I wanted to use for initial BC i used cyclic BC and kqr and epsilonwallfunction at top and bottomwall for k and epsilon.

The results are the ones in my first post. I don't have a clue why my velocities are too small, especially near wall?!

Best Wishes,
Danesh

[Lieven]

Hi Danesh,

RAS-modeling gives you averaged profiles. Exactly the ones you shouldn't impose ;-)

Simply run your LES simulation with cyclic boundary conditions, start from a uniform field and the turbulence will be generated by itself. After your solution stabilizes (monitor for example the total kinetic energy in your system), perform a time-averaging of the velocity. It is this time-averaged velocity profile that you should compare with the DNS data.

Cheers,

Lieven

[DaSh]

Hi again Lieven,

thank you again. My problem now is, that I did the exact same thing. I used cyclic BC in 0 folder and uniform (0 0 0) at top and bottom wall. But I only get the results above. I thought my approach would be totally wrong. I wonder why the turbulence does not generate itself. It goes up to Re_tau = 160 and stabilizes there. Whereas I induced the parameters necessary for Re_tau = 395.

Am I missing a point?

Greets,

Danesh

[Lieven]

Do you impose a pressure gradient to force the flow?

[morard]

Hi DaSh,

search for the perturbU utility. It's written some years ago. It gives you initial field and you can generate turbulence very fast.

Regards

[ashvinc9]

Hi DaSh,

Here, I attached the perturbU utility (thank to original author). This will generate initial perturbations in your 0 (zero) directory based on the informations of nu, Retau and Ubar defined in the constant/transportProperties file. So just write the following in your transportProperties.

Ubar            Ubar [ 0 1 -1 0 0 0 0 ] ( 13.2 0 0 ); // your value of mean velocity 
nu              nu [ 0 2 -1 0 0 0 0 ]     1.975e-06; // your value of nu
Retau           Retau [ 0 0 0 0 0 0 0 ]  4000; // your value of ReTau 

// change the values as per your requirement

So just compile the utility (first wclean and then wmake) and keep above info in the transportProperties file.

-Ashvin

[DaSh]

Good Morning,

thanks again Lieven, Dejan and Ashvin for your replies. I will try to use perturbu for the generation of initial conditions.

@Lieven:

boundaryField
{
bottomWall
{
type zeroGradient;
}
topWall
{
type zeroGradient;
}
sides1_half0
{
type cyclic;
}
sides2_half0
{
type cyclic;
}
inout1_half0
{
type cyclic;
}
inout2_half0
{
type cyclic;
}
sides2_half1
{
type cyclic;
}
sides1_half1
{
type cyclic;
}
inout1_half1
{
type cyclic;
}
inout2_half1
{
type cyclic;
}
}

This is my 0/p. I just used cyclic BC on inlet and outlet. Both halves of inout1 are considered the inlet both of inout2 the outlet. Shouldn't a pressure gradient be imposed automatically or do I really need to specify a gradient between in and out by uniform values?

Thanks again!

Danesh

[Lieven]

Shouldn't a pressure gradient be imposed automatically or do I really need to specify a gradient between in and out by uniform values?

Well, you should impose the pressure gradient explicitly. But not by setting values at inlet and outlet. It's simple to see that this won't work: since the problem is cyclic, the outlet is basically equal to the inlet for velocity and all other parameters. If you would set the pressure at inlet and the outlet explicitly, you basically set 2 pressures at 1 point. This won't work for 2 reasons: 1. openfoam does not accept to set any other boundary condition than 'cyclic' on cyclic patches, and 2. if it would accept it, for sure you would get extreme gradients in velocity etc.

So if you are using OF 2.2.x you should use the fvOptions functionallity 'pressureGradientExplicitSource'. If you are using an older version have a look at the implementation of the channelFoam solver.

Cheers,

Lieven

[DaSh]

Thanks for explaining Lieven. I will try this and post my conclusions/results tomorrow. I use OpenFOAM 2.1.x btw.

Cheers, ;-)

Danesh

[Lieven]

It might be that it takes a bit longer than one day to get it working ;-)

[DaSh]

Sure thing. I meant, I would post if I was able to apply the necessary changes to make it work fine. So more conclusions than results. :-)

Thanks again!

[DaSh]

Hi again,

I looked into the code of ChannelFoam. What I don't get is the changes I would have to make, to make my boundaries work. That is because, if I am correct, the channelFoam solver calculates a gradP on its own by reading the Ubar I give in transportProperties.

Although I get why giving values to cyclic boundaries is wrong, I don't get how i should impose an "additional" gradP, because of the solver calculating it by itself. (At least it should).


Kind regards,

Danesh

[Lieven]

Hi Danesh,


Were you already using the channelFoam solver? Cause based on the fact that you mentioned you were using RAS profiles I assumed you were not (channelFoam accepts only LES turbulence models). If you are, you are correct the pressure gradient should be imposed already based on comparing the actual mean flow rate with the requested mean flow rate (from the transportProperties).

But if you are using pisoFoam, you need to include tis pressure gradient yourself in the equation. You can follow either this approach, so imposing a flow rate, or you can directly set 'gradP' as a fixed value.

Cheers,

Lieven

[DaSh]

Hi Lieven,

yes you are right, I did try to use RAS to generate the initial condition. Which you said is wrong because it is averaged. By the way, could you tell me, why it is physically wrong to use Reynolds Averaged values as initial values for LES?

I am just wondering why i don't get acceptable results with the ChannelFoam solver then, without generating initial solution. Cyclic boundaries should suffice then. I have to take a deeper look into this....

Regards,

Danesh

PS: I get very good results using the perturbU utility, so thanks again for the recommendation!

[Lieven]

Hi Danesh,

Averaged profiles are not instantaneous profiles. You will never see them in real life as in 'hey look, here I have the log-profile'. It doesn't work like that. You obtain them after time averaging the instantaneous profiles.

What you do with LES is solving instantaneous flow fields. At not a single instance should your result look like the time-averaged profile. Only after time-averaging should you obtain these profiles. Imposing RANS-profiles at the inlet conflicts with this fact and is physically pure nonsense (in more scientific terms, you are messing up the time scales in your simulation).

With the ChannelFoam solver you should get the right profiles. Even when you start from a uniform velocity field. If not, there still is something incorrect in your case setup and my first guess would be that the solution hasn't converged yet. You can check this for example by monitoring the (mean) kinetic energy in the system:

volScalarField Ek("Ek",0.5*(U & U));
Info<<"mean Ek: " << gAverage(Ek) << nl << endl;

If this parameter stabilizes you reach the point where you want to start averaging the velocity fields (you can use the fieldAverage functionObject) for this. Take at least 30 cycles as averaging time...

Cheers,

Lieven

[DaSh]

Hi Lieven,

I hope you had a good weekend. I implemented the monitoring of the kinetic energy like this now:

const volScalarField& Ek = mesh().lookupObject<volScalarField>("Ek");
Info<<"mean Ek: " << gAverage(Ek) << nl << endl;

Since your code sample gave me IO Error in relation to "U" being unknown, I tried this other method and it seems to be working.

I'll keep you informed.

Thanks and Cheers,

Danesh

[Lieven]

Hi Danesh,

It just depends how you implement the code. If you include it in the solver directly, it should work since 'U' is simply the velocity. If you want to write it as a coded function object, you need to add

const volVectorField& U = mesh().lookupObject<volVectorField>("U");

Cheers,

L