CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

LES: Turbulent Channel Flow without initial solution (BC)

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

Like Tree18Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 29, 2013, 06:51
Default LES: Turbulent Channel Flow without initial solution (BC)
  #1
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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 is offline   Reply With Quote

Old   July 31, 2013, 05:51
Default
  #2
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   July 31, 2013, 09:03
Default
  #3
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
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
Lieven is offline   Reply With Quote

Old   July 31, 2013, 09:08
Default
  #4
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   July 31, 2013, 09:16
Default
  #5
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
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
Elham, songwukong, DaSh and 2 others like this.
Lieven is offline   Reply With Quote

Old   July 31, 2013, 09:27
Default
  #6
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   July 31, 2013, 09:29
Default
  #7
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
Do you impose a pressure gradient to force the flow?
Lieven is offline   Reply With Quote

Old   July 31, 2013, 12:42
Default
  #8
Member
 
Dejan Morar
Join Date: Nov 2010
Posts: 78
Rep Power: 17
morard is on a distinguished road
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
songwukong, DaSh and zhutaihang like this.
morard is offline   Reply With Quote

Old   July 31, 2013, 19:20
Default perturbU utility
  #9
New Member
 
Ashvin Chaudhari
Join Date: Aug 2011
Location: Finland
Posts: 23
Rep Power: 15
ashvinc9 is on a distinguished road
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.

Code:
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
Attached Files
File Type: zip perturbU.zip (8.1 KB, 189 views)
fumiya, songwukong, DaSh and 4 others like this.
ashvinc9 is offline   Reply With Quote

Old   August 1, 2013, 04:07
Default
  #10
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   August 1, 2013, 07:25
Default
  #11
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
Quote:
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
mgg, DaSh and hhu_lulu like this.
Lieven is offline   Reply With Quote

Old   August 1, 2013, 09:23
Default
  #12
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
Thanks for explaining Lieven. I will try this and post my conclusions/results tomorrow. I use OpenFOAM 2.1.x btw.

Cheers, ;-)

Danesh
DaSh is offline   Reply With Quote

Old   August 1, 2013, 09:38
Default
  #13
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
It might be that it takes a bit longer than one day to get it working ;-)
Lieven is offline   Reply With Quote

Old   August 1, 2013, 10:23
Default
  #14
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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 is offline   Reply With Quote

Old   August 2, 2013, 05:34
Default
  #15
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   August 2, 2013, 05:42
Default
  #16
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
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
Lieven is offline   Reply With Quote

Old   August 2, 2013, 06:04
Default
  #17
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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!
DaSh is offline   Reply With Quote

Old   August 2, 2013, 06:33
Default
  #18
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
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:
Code:
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
Lieven is offline   Reply With Quote

Old   August 6, 2013, 05:39
Default
  #19
New Member
 
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13
DaSh is on a distinguished road
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
DaSh is offline   Reply With Quote

Old   August 6, 2013, 05:49
Default
  #20
Senior Member
 
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22
Lieven will become famous soon enough
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
Code:
const volVectorField& U = mesh().lookupObject<volVectorField>("U");
Cheers,

L
Lieven is offline   Reply With Quote

Reply

Tags
channel flow, convergence, initial condition, les

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Floating point exception error Alan OpenFOAM Running, Solving & CFD 11 July 1, 2021 22:51
pimpleFoam: turbulence->correct(); is not executed when using residualControl hfs OpenFOAM Running, Solving & CFD 3 October 29, 2013 09:35
How to write k and epsilon before the abnormal end xiuying OpenFOAM Running, Solving & CFD 8 August 27, 2013 16:33
pisoFoam - unstable pressure residual Industrial_CFD OpenFOAM Running, Solving & CFD 21 February 24, 2013 16:39
Orifice Plate with a fully developed flow - Problems with convergence jonmec OpenFOAM Running, Solving & CFD 3 July 28, 2011 06:24


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