CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   LES of turbulent channel flows (https://www.cfd-online.com/Forums/openfoam-solving/57889-les-turbulent-channel-flows.html)

canopus June 24, 2015 11:42

unable to get log law in LES
 
1 Attachment(s)
Hi, I am doing a LES of channel flow using
cyclic boundary conditions and mentioning ubar in fvOptions
stretched mesh with SR=1.15
first point y+ < 1 and smagorinsky without any wall function
fvSchemes and fvSoultions are form channel395 tutorial
dimensions,velocity and viscosity are different but give Re_{\tau}=450.

When I plot u+ vs y+ I get a very bad profile as attached in log law region.
Any suggestions on what might be going wrong?

cedric_duprat June 25, 2015 03:08

Dear Canopus,

Are you sure about your Reynolds number ? notice that Re is not Re_tau

What are the size of you domain, velocity and viscosity ?

Could you also post your fvScheme and fvSolution ?

How have you calculated your y+ and u+ ?

Have you plotted U = f(y) to see the global shape of your velocity profile, is it converged, flat at the center, or has it a parabolic shape ?

how have you initialized your calculation ?

These answers will help us to give you feed back on your calculation

Regards,

Cedric

canopus June 25, 2015 09:10

4 Attachment(s)
Dear Cedric Thanks for taking your time out!

The details of the LES are as follows


Domain
8h X 2h X 8h (x y z where x is streamwise, y normal and z spanwise)
Reason for having large z is to serve as precursor of wide geometry

Velocity (bulk) = 26m/s
kinematic viscosity = 1.46e-05

perturbUChannel utility is used to assign initial field and then large number of time steps run to achieve turbulent flow


Re(bulk) ~ 30000 -> Re(tau) = 450 (based on half channel width)
U in x-y plane snapshot attached

fvScheme and fvSolution are attached

postprocessing:
postChannel utiliy run as periodic in stremawise and spanwise direction
file Uf.xy is used to get
dU/dy | y=0 using first row of data
uTau = sqrt(nu* |1dU/dy|y=0)
ReTau = uTau*h/nu

u+=u/uTau
y+=y*uTau/nu

U = f(y) is attached

cedric_duprat June 26, 2015 02:16

Dear Canopus,

that's strange ...
Are you sure your statistics are converged. I mean how many cross-flow have you done before averaging ? you should not averaged from the begining of your calculation because the initial flow will be taken into account which is wrong.

You're instantaneous snapshot looks good but if you are not converged, the average field will not be ok. And according to you first graph, your velocity looks more a laminar profile than a turbulent one.

otherwise, are you sure about your dudy|y=0 calculation ? if utau is wrong, you might also have strange results.

I hope this will help you,

Cedric

canopus June 26, 2015 02:55

@Cedric Thanks again for your comments!

The flow through is 5 time based on u_Tau and is less I know.
Do you think that its going to improve with more flow throughs?

postChannel utility I believe computes based on collapsing streamwise and spanwise data of a particular instantaneous 3-D field.
So I guess time evolution of flow is not taken account?
Please Correct me if wrong.

Is something wrong in calculation of u_Tau from Uf.xy obtained by running
Code:

postChannel -latestTime
Anyone experienced strange problems with stretching ratio (here 1.15)?

cedric_duprat June 26, 2015 04:20

Dear Canopus,

I'm sure that if you run a calculationo from scratch (using perturbU), starting your averaging procedure at t=0 and doing only 5 cross flow it's definitly not enough.
I'm not sure to understand what is a cross flow based on utau ?

You could try that: double you calculation time, and check if at the end, you have got the same results. if yes, that would mean that you had been already converged, if not, that you need to converge your calculation more.

About the stretching, you need to check that you have at least 3, 4 points into your viscous layer (because you're not using wall function) to calculate the shear stress correctly. if you first points is at y+ = 0.3 and the second one a 10, that's not good.

I hope this will help you

Cedric

canopus June 26, 2015 04:52

@Cedric thanks for your prompt response.

Dividing the channel length by friction velocity kind of gives flow through time 5.
Of course one can also use bulk velocity and compute a flow through time.

NB: 5 flow times is from the onset of turbulence and equals almost 50 flow times based on bulk velocity from onset of turbulence.

Grid has 8 points in y+ < 10 with 1st point < 1 and stretching ratio =1.15

Any comments on postChannel & u_Tau calculation?

canopus June 26, 2015 05:32

@ Cedric how did you compute the u+ vs y+ log plot in your first poset of thread?
Can you please elaborate a bit?

I suspect that there is a stupid mistake in my post processing. :o

cedric_duprat June 26, 2015 08:00

:)
as you can see it was few years ago.

But as you proposed, I used postChannel to get Uf and then I calculated tau_w (or utau) to get y+ and u+.

It's true that your plot U=f(y) looks good (turbulent) and that your u+ = f (y+) is close to a laminar profile.

Could it be something like a factor 2 in tau_w due to face value vs cell center value ?

If you are confident with your calculation, maybe you could do a longer calculation .... just to check that your averaging procedure is converged.

Cedric

canopus June 26, 2015 09:48

Dear Cedric seems like some light at end of tunnel..

can you please elaborate -
Quote:

factor 2 in tau_w due to face value vs cell center value ?

cedric_duprat June 29, 2015 03:13

Dear Canopus,

well, to calculate dudy|y=0 I guess your first point is y=0 U=0. The question is then where is your second points; the cell center or the face value between the 1st and the 2nd point. Depending of that, you might have a factor 2 in the wall normal direction.
To answer this question, you have to check the postChannel routine.

Cedric

canopus June 29, 2015 14:51

Dear Cedric
I will check the postChannel.
But just a thought -
As long as the velocity values correspond to the wall normal values
it should not matter whether it is face center or cell center as
u_Tau depends on difference of u and y for first set of points?

HanSolo123 July 1, 2015 15:16

Hi,

I have just sent you a message!

tiam July 2, 2015 08:41

Quote:

Originally Posted by canopus (Post 552243)
@ Cedric how did you compute the u+ vs y+ log plot in your first poset of thread?
Can you please elaborate a bit?

I suspect that there is a stupid mistake in my post processing. :o

postChannel will give values averaged among all the x-z "layers" you have in your mesh, so the first value will be the one in the cell-center of the wall-adjacent cell. So you should divide by half the size of the first cell in the wall-normal direction to compute the gradient.
Also, don't forget to use the mean velocity, not the instantaneous one. In my experience even the patch-averaged instantaneous u_tau changes quite a lot in time.

To avoid concerns with u_tau things, I suggest that you grab some DNS data and compare with what you get in global coordinates. That can give you a reasonable idea of whether you are doing fine or not.

Also, don't underestimate the amount of averaging time that is needed, and as Cedric points out, don't start the averaging directly, allow some time to flush away the transients related to ICs etc. I used 1000 seconds for the Re_tau = 395 simulations.

canopus July 2, 2015 09:21

Dear Timofey
Thanks for your suggestions.
I already started with uTau for Channel 395 :)

on running postChannel -latestTime outputs graphs/ Uf.xy
Uf.xy contains U vs y as two columns where y is the cell center co-ordinate.
I have checked the 1st y point in Uf.xy is half of 1st y point in constant/polymesh/points.
As I am using these two values for computing u_Tau I think division by 2 is not needed(hopefully?)

postChannel doesn't do any time averaging but spatial averaging I suppose.
So what do you mean velocity?

When you talk about time averaging do you mean averaging output of postChannel over several time periods?

tiam July 2, 2015 09:28

Quote:

Originally Posted by canopus (Post 552997)
Dear Timofey
Thanks for your suggestions.
I already started with uTau for Channel 395 :)

on running postChannel -latestTime outputs graphs/ Uf.xy
Uf.xy contains U vs y as two columns where y is the cell center co-ordinate.
I have checked the 1st y point in Uf.xy is half of 1st y point in constant/polymesh/points.
As I am using these two values for computing u_Tau I think division by 2 is not needed(hopefully?)

postChannel doesn't do any time averaging but spatial averaging I suppose.
So what do you mean velocity?

When you talk about time averaging do you mean averaging output of postChannel over several time periods?

Yes, I forgot that postChannel does not actually let you choose the fields that you want to average.
It will try to find the UMean automatically, which is the time-averged velocty. I guess you are producing that with the fieldAverage function object, right?

canopus July 2, 2015 10:58

Yes I do use fieldAverage function object and have UMean file in the time directory for which I run postChannel.
I case I just have to wait for large number of flow times!!!

I hope you agree to not using the factor 2?

tiam July 2, 2015 17:54

Quote:

Originally Posted by canopus (Post 553020)
Yes I do use fieldAverage function object and have UMean file in the time directory for which I run postChannel.
I case I just have to wait for large number of flow times!!!

I hope you agree to not using the factor 2?

I have actually used a different way to calculate the u_tau. I used a function object to calculate y+ and then used that to get the u_tau. One can of course calculate the u_tau directly as well. You do need swak4foam installed for it though. A nice thing with this one is that you can see how the average u_tau converges.

You can check out my setup and the results for Re_tau = 395 at
https://bitbucket.org/lesituu/channel_flow_data

But I think using the averaged velocity profile should work fine, it is the same calculation.

ykanani July 6, 2015 19:51

Quote:

Originally Posted by canopus (Post 552237)
@Cedric thanks for your prompt response.

Dividing the channel length by friction velocity kind of gives flow through time 5.
Of course one can also use bulk velocity and compute a flow through time.

NB: 5 flow times is from the onset of turbulence and equals almost 50 flow times based on bulk velocity from onset of turbulence.

Grid has 8 points in y+ < 10 with 1st point < 1 and stretching ratio =1.15

Any comments on postChannel & u_Tau calculation?


You can also use pressure gradient to calculate u_tau as indicated in the turbulent flows by Pope:
dp/dx = u_tau^2 / (2*delta)
which delta is the channel half width

you can look for dp/dx in the timedirectory/uniform/momentumSourceProperties
which is indicated as "gradient"

Hope it helps.

Elham July 17, 2016 23:05

RAS better that LES
 
Hi every body,

I am simulating turbulent flow inside a channel. The channel size is 60*10*10(mm) and number of mesh are 300*80*80. I want to produce fully turbulent flow by means of mapping method. I produced a relatively good result with RAS. When I map data to LES the results get worse and not turbulent at all. And it takes so long time to proceed, eg. a full week just to proceed 0.2 sec.

I will appreciate if anyone can give me a clue.

Regards,

Elham


All times are GMT -4. The time now is 00:50.