[wenxu]

Many thanks for your detailed reply, Hans.

I do not know if I understand it correctly. Let me rephrase your results. For resolved kinetic energy Kgs, we calculate it as follows,
Kgs = 0.5*(<U>^2 + <V>^2 + <W>^2)

For unresolved kinetic energy (SGS) part, we calculated it with the LES SGS model, e.g. Smagorinsky used here,

Ksgs = (2.0*ck_/ce_)*sqr(delta())*magSqr(dev(symm(gradU)));

I do not know whether it is an error in this attached figure. The DNS should calculate ALL of the energy, so, ksgs_DNS should be equal to ZERO. Rather than equal to Kg or Ktotal.

Then, if we want to know how much the kinetic energy is solved with our specific discretization scheme and mesh resolution, we can calculate the turbulence resolution as follows,

M = Kgs/(Kgs+ Ksgs)

For LES, M should be larger than 80% (Pope, NJP).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

But the confusing thing is, the above criteria is applied for EVERY cell, that means in EVERY cell, the resolved kinetic energy should be larger than 80%. But in your case, if I understand it correctly, you sample the data in the y+ direction, when in the other directions (x+, z+), you do average on them. In this case, how can you ensure the results you got can be applied for all the computation domain in your simulation? I mean, if you use the stretched mesh in the flow direction, then in the downstream, the mesh is coarse, even if you get the 90% resolved TKE in the upstream in the spanwise direction, then the results should not be convincing. Because in the downstream of the spanwise direction, there may be only 60% TKE is resolved where the mesh is coarse. Thus, my suggestion is to extract the data from the x-y plane in the flow direction, in this case, we can get the result with all levels of mesh resolution. My result is attached.

Many thanks for your kind reply. I am looking forward to hear from you for your suggestions.

Best regards,
Xu

[HanSolo123]

Originally Posted by wenxu

Many thanks for your detailed reply, Hans.

I do not know if I understand it correctly. Let me rephrase your results. For resolved kinetic energy Kgs, we calculate it as follows,
Kgs = 0.5*(<U>^2 + <V>^2 + <W>^2)

For unresolved kinetic energy (SGS) part, we calculated it with the LES SGS model, e.g. Smagorinsky used here,

Ksgs = (2.0*ck_/ce_)*sqr(delta())*magSqr(dev(symm(gradU)));

I do not know whether it is an error in this attached figure. The DNS should calculate ALL of the energy, so, ksgs_DNS should be equal to ZERO. Rather than equal to Kg or Ktotal.

Then, if we want to know how much the kinetic energy is solved with our specific discretization scheme and mesh resolution, we can calculate the turbulence resolution as follows,

M = Kgs/(Kgs+ Ksgs)

For LES, M should be larger than 80% (Pope, NJP).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

But the confusing thing is, the above criteria is applied for EVERY cell, that means in EVERY cell, the resolved kinetic energy should be larger than 80%. But in your case, if I understand it correctly, you sample the data in the y+ direction, when in the other directions (x+, z+), you do average on them. In this case, how can you ensure the results you got can be applied for all the computation domain in your simulation? I mean, if you use the stretched mesh in the flow direction, then in the downstream, the mesh is coarse, even if you get the 90% resolved TKE in the upstream in the spanwise direction, then the results should not be convincing. Because in the downstream of the spanwise direction, there may be only 60% TKE is resolved where the mesh is coarse. Thus, my suggestion is to extract the data from the x-y plane in the flow direction, in this case, we can get the result with all levels of mesh resolution. My result is attached.

Many thanks for your kind reply. I am looking forward to hear from you for your suggestions.

Best regards,
Xu

Hi Xu,

sorry for late reply. I fear that I cant answer your questions to your satisfaction - too much time has past since I have put all my effort in this topic.

First of all you are right. The DNS plots in the figues with k_gs and k_sgs are not correct if you just look at this picture. But I have mentioned in the text in my thesis that I plot the DNS data there to give the reader the chance to see the rate of k_gs and k_sgs compared to the DNS data on the first sight.

The sencond part of your question is difficult for me to answer. We have to seperate time-averaging and area-averaging.

In this case, how can you ensure the results you got can be applied for all the computation domain in your simulation?

I think it is possible because of the boundary conditions of the channel flow. The sides of the computation domain are cyclic. If you have a good initial solution and if you time-average the flow in the whole domain for enough flow throughs, there is just a wallnormal (y) dependency of the flow profile.

As the following step, in my opinion it is allowed to do an area-average in x- and z-direction with the postChannel utility to get the data that is shown in the picture i attached because there should be no dependency in those directions of the flow.

I think the postChannel utility does exactly this, an average in x- and z-direction, but I am not 100% sure.
In postChannel.C it is said:

        // Average fields over channel down to a line
#       include "collapse.H"

so the answer should be in collapse.H.


If you dont do the area-average and just get the results over a line in y-direction e.g. in paraFoam at an arbitrary x- and z- position, and plot this non-average energies over y, there should be just a very very small difference to the averaged-results (if you have a well suited flow development and enough flow-throughs for time-average)

If it is the case - in my opinion - it can be said that the results can be applied to the whole domain.


Im sorry that I cant say anything to your attaced figure. I havent seen such a plot in my study.


3rd part:

Yes, I have used gnuplot to make my figures. I have made the size of all figures in a way that they fit well on a DIN A4 page. I am not familiar with scientifi papers either.

I configured it with:

set term tikz standalone color solid size 14.8cm,15cm font ',12'
set output 'kPlus.tex'

The code for the plots is just standard .
To replace a certain axis-number, just say:

set ytics add ('$k_{gs}^+$' 5)

It will replace at y-axis at position 5 the digit with '$k_{gs}^+'.
Note that it is LaTex code. gnuplot will generate a file 'kPlus.tex' as mentioned above. Then I needed to translate this with my latex editor and it gave me a pdf with the figure and the text.

[wenxu]

First, thank you for your very kind and detailed reply. Really a nice guy. :>)

I do not have confusion with the time-averaging and area-averaging. :>)

I mean in the x direction (the flow direction), if you use the stretched mesh, then for a give x point, then you sample the data along the spanwise direction (y direction), you may get an unreal result. In other words, if the point x is in the upstream where you have refined your mesh, then you may get a very small SGS kinetic energy. However, the possible (also bad) thing is that in the downstream where you stretch your mesh (much coarse than that in the upstream), then the SGS kinetic energy can be very large, say below 80%. Then how can you justify your result if you only based your data in the upstream flow?

So, to resolve the potential problem, my suggestion is to sample the data over the domain OR only in the x-y plane. In this way, we have covered all possible mesh. The result is more believable.

But if the uniform mesh is used in you case, the problem I list above will not happen. Since the turbulence length scale in the upstream will be certainly much small than that in the downstream.

This paper is suggested to read: LES OF THE SYDNEY SWIRL FLAME SERIES: AN INITIAL INVESTIGATION OF THE FLUID DYNAMICS.

Many thanks for your kind reply. I really know it is hard to answer something if that has past a long time.

Have a nice day!

My best wishes,
Xu

[HanSolo123]

Ah ok, I think I got what you mean.

I have indeed used an uniform mesh in x- and z-direction. Just in wallnormal y-direction I have had configured a ratio.
The xPlus and zPlus values I have posted at April 2, 2016, 12:26 are constant for the whole mesh. For yPlus I had 1 at the first wall cell with increasing yPlus to the middle of the domain.

A very nice discussion :-)