|
[Sponsors] |
LES: Turbulent Channel Flow without initial solution (BC) |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 29, 2013, 06:51 |
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 |
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+ .... |
|
July 31, 2013, 05:51 |
|
#2 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
July 31, 2013, 09:03 |
|
#3 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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 |
|
July 31, 2013, 09:08 |
|
#4 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
July 31, 2013, 09:16 |
|
#5 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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 |
|
July 31, 2013, 09:27 |
|
#6 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
July 31, 2013, 09:29 |
|
#7 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
Do you impose a pressure gradient to force the flow?
|
|
July 31, 2013, 12:42 |
|
#8 |
Member
Dejan Morar
Join Date: Nov 2010
Posts: 78
Rep Power: 17 |
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 |
|
July 31, 2013, 19:20 |
perturbU utility
|
#9 |
New Member
Ashvin Chaudhari
Join Date: Aug 2011
Location: Finland
Posts: 23
Rep Power: 15 |
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 -Ashvin |
|
August 1, 2013, 04:07 |
|
#10 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
August 1, 2013, 07:25 |
|
#11 | |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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 |
||
August 1, 2013, 09:23 |
|
#12 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
Thanks for explaining Lieven. I will try this and post my conclusions/results tomorrow. I use OpenFOAM 2.1.x btw.
Cheers, ;-) Danesh |
|
August 1, 2013, 09:38 |
|
#13 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
It might be that it takes a bit longer than one day to get it working ;-)
|
|
August 1, 2013, 10:23 |
|
#14 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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! |
|
August 2, 2013, 05:34 |
|
#15 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
August 2, 2013, 05:42 |
|
#16 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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 |
|
August 2, 2013, 06:04 |
|
#17 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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! |
|
August 2, 2013, 06:33 |
|
#18 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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; Cheers, Lieven |
|
August 6, 2013, 05:39 |
|
#19 |
New Member
Danesh S
Join Date: Jul 2013
Location: Bochum, Germany
Posts: 27
Rep Power: 13 |
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 |
|
August 6, 2013, 05:49 |
|
#20 |
Senior Member
Lieven
Join Date: Dec 2011
Location: Leuven, Belgium
Posts: 299
Rep Power: 22 |
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 |
|
Tags |
channel flow, convergence, initial condition, les |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |