Hi Jianying and Ning, I jus
 

Hi Jianying and Ning,

I just want to add that the reference DNS calculation we used to compare our calculation was done with a second order code (in both time and space).
So if you use (real) second order scheme with an accurate mesh, there are no reason to get DNS data.

You can check easily your mesh (close to the wall) but for the numerics .... I don't know.

Cedric

Hi Cedric: Obviously if you
 

Hi Cedric:

Obviously if you refine the grid, you should be able to get better results. I compared my data with Moser's data, published in physics of fluids. I don't think they use a second-order code.

Ning

Hi Cedric: Obviously if you
 

Hi Cedric:

Obviously if you refine the grid, you should be able to get better results. I compared my data with Moser's data, published in physics of fluids (1999). I don't think they use a second-order code.

Ning

Hi Ning I tried the one equat
 

Hi Ning
I tried the one equation model, smagorinsky, and dynsmagorinsky, but above my results used the dynsmagorinsky model, not smagorinsky model. my results of dynsmagorinsky model is better than one equation model.
my mesh is poorer than yours, but others are the same as yours.

Hi Cedric
My results isn't better than DNS data, I know my mesh is poor. If increasing mesh, the time of computation increases. If a third-order of the temporal discretization term is used, the time of computation is less than the time of computation of a second-order of the temporal discretization term and increasing mesh.

gave me some advices.
Jianying

Hi Ning I tried the one equat
 

Hi Ning
I tried the one equation model, smagorinsky, and dynsmagorinsky, but above my results used the dynsmagorinsky model, not smagorinsky model. my results of dynsmagorinsky model is better than one equation model.
my mesh is poorer than yours, but others are the same as yours.

Hi Cedric
My results isn't better than DNS data, I know my mesh is poor. If increasing mesh, the time of computation increases. If a third-order of the temporal discretization term is used, the time of computation is less than the time of computation of a second-order of the temporal discretization term and increasing mesh.

gave me some advices.
Jianying

Has anybody tried Re_tau = 180
 

Has anybody tried Re_tau = 180?

Just Curious... I'm a complete
 

Just Curious... I'm a complete newbie out here.. Is there any tutorial to get started with DNS/LES of Channel Flow?? What machines do you guys run your code on???

I tried the Re_tau=180 case and it produced acceptable results. I did some analysis at Re_tau=395 using one eq eddy and dyn one eq model. The results obtained using the localized dynamic one equation model was much better than the one eq case with Van Driest damping on a 64 cube grid with 2pi*2*pi domain and the same numerical discretization as the tutorial. Has anyone tried using their own filter width expression instead of the smooth/cuberoolvol filter ? Also majority of the papers which i came across used higher order schemes with LES and that can be another reason for the problem.

Dear Cedric.

You say you are NOT using limitedLinear 1 for the two terms mentioned.
Can you tell me which one you are using?
Ore actually post your fvSchemes dictionary?

I'm having some problem using oneEqEddy in a square duct LES.
My results are poor and Smagorinsky is far better ...
I don't think thats correct ...

Have a nice day. Sebastian

Hello World.

As mentioned above I am doing the channel flow simulation in a square duct with cyclic bc's for in- and outflow.
My Resolution is 56x56x70 with refined mesh towards the wall so there are 7 cells within y+ < 10.

I'm using two different LES models, namely

• Smagorinsky (SMG)
• One Equation Eddy

with two different filter-widths (Delta) each time, namely

• Cube Root Volume (CRV)
• van Driest Damping

Well, the results with Smagorinsky are looking more or less good, the results with the One Equation Eddy are scrap.

I'm even experiencing that the velocity profile is not symmetric.
Unfortunately the asymmetry looks to be getting worse when simulation longer and thus doing longer averaging.

Important information on how these plots are obtained: I'm using my own post-processing tool for averaging in the flow-direction (with MATLAB). I'm not primary doubting my own tool, but is there an OpenFOAM tool for post-processing a square duct channel?

Any ideas why the One Equation model is so bad compared to both DNS and Smagorinsky? Well, I expected vice versa.

I would like to know what is meant by the final pressure gradient?
Is this the averaged pressure gradient at the end of the simulation?

I guess he meant gradP.raw :):D;):cool::rolleyes:

Which is written in the last uniform sub-directory of the last time-step?
Just to make sure ...

Your objective is?? Why do you care about it? :D:)

I think you have read my previous posts and know I'm having some difficulties with my LES simulations. Just to make sure I'm not getting something wrong on the way (for example how and where to read gradP to get utau) I'm just asking.

Am I missing something??? As I remember, I have never used gradP to get U_tau. :confused::confused::confused::eek::eek::eek:

Well, but I do.

utau = sqrt( -D/(4*rho) * gradP )

with D beeing the diameter of the Duct.

:eek: I see. ......
I calculate u_taw from a wallShearStress utility, of cause in an averaging sense.

^^^^^^^^^
I guess they are the same, since the essence are the same, right?

I hope so ...

Hi, can anyone tell me how did you get the U+ versus y+ data?

My results is wrong, so I lost my idea about the procedure...

1. Get wall shear stress
2. Calculate U_tau, (wSS denotes wall shear stress)
3. Plot U+ versus y+, (nuTmp denotes the value of nuEff)
Is the procedure right?