LES: Turbulent Channel Flow without initial solution (BC)
Hello fellowFOAMers,
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 ydirection. I use the Smagorinsky Model with VanDriest damping. Trying to solve the problem without an initial solution (boundary condition) in 0Folder leaves me with the following (blue is LES, red DNS results from THTLab Tokyo). http://s14.directupload.net/images/130729/bnwutul5.png Thereafter I have tried to generate a initial BC using a RASModel until it converged, using its solution as new 0folder 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+ .... 
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 
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 
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 
Hi Danesh,
RASmodeling 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 timeaveraging of the velocity. It is this timeaveraged velocity profile that you should compare with the DNS data. Cheers, Lieven 
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 
Do you impose a pressure gradient to force the flow?

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 
perturbU utility
1 Attachment(s)
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 Ashvin 
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 
Quote:
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 
Thanks for explaining Lieven. I will try this and post my conclusions/results tomorrow. I use OpenFOAM 2.1.x btw.
Cheers, ;) Danesh 
It might be that it takes a bit longer than one day to get it working ;)

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! 
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 
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 
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! 
Hi Danesh,
Averaged profiles are not instantaneous profiles. You will never see them in real life as in 'hey look, here I have the logprofile'. 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 timeaveraged profile. Only after timeaveraging should you obtain these profiles. Imposing RANSprofiles 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)); Cheers, Lieven 
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 
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"); L 
All times are GMT 4. The time now is 10:08. 