[hadi]

Thank you henry,

Is it possible to have this paper?

Hadi

[kumar2]

Hi Hadi,

What delta did you use while running channelOodles with Smagorinsky model ? was it a cubeRootDelta . I am refering to your post and figure dated -Monday, October 22, 2007 - 03:09 am.

Thanks a lot

regards

kumar

[kumar2]

Hi Hadi,

When you used the Crank nicholson scheme, were you able to run your computations with

ddt(U) CrankNicholson 1; or did you use a smaller fraction such as 0.5 or 0.75. When i run my computations(channelOodles - tutorial) with ,ddt(U) CrankNicholson 1; , i get fluctuations in mass flow rate.

Thanks

Regards

Kumar

[kumar2]

Dear Friends,

I have been trying to repeat the flow in a channel, as detailed in the publication 'Large Eddy Simulation of Turbulent Channel Flows' . I have followed the same approaches mentioned in the paper. I am using the Deardorff model . The length of the channel is 1550 wall units. The width is 775 wall units. y+ is about 1. x+ is about 20 and z+ is about 25. the aspect ratio of the cells in the streamwise direction is about 10 , in the spanwise direction it is about 14. The number of cells in the wall normal direction resolving the boundary layer is 50 with an expansion factor of 11. ( What i am doing is a more resolved tutorial case). The grid is 240000 cells (80*100*30) I am using a fully non linear crank nicholson scheme ( ddt(U) crankNicholson 1.0;) .All othet schemes are as in the tutorial , and are linear .

My openfoam results are generally close to the results from the publication ( i have taken fig1(a) of publication). But in the region ( 7 < y+ < 70 ), there is a noticeable difference between them. It looks like my results have a lot more dissipation. I was wondering if a larger number of cells in the wall normal direction between 7 < y+ < 70 would improve my results. Or is there a major mistake in my settings.

Thanks a lot

Kumar

[ngj]

Hi Kumar

It could be interesting, if you could compare your results with the van Driest profile. It fits well with experimental data up to order of magnitude y+=1000.

Best regards,

Niels

[kumar2]

Hi Neils,

Thanks a lot for your suggestion. i am indeed going to grab the van driest profile and fit my data and compare.

But what concerns me is why my results are different from that in the publication. i feel there is more dissipation in my grid. what do you think ?

thanks again

kumar

[ngj]

Hi Kumar

I do not have the mentioned article, but let us assume that the results in that article is the truth
I haven't spend time on channelOodles yet, so please correct me if I am wrong. The eddy viscosity is calculated based on some approach ... is it so that there is a factor in this approach which gives the eddy viscosity?
Again say that the article is correct, then you have a hard time getting the correct slope of your velocity profile, which tells me that either your discretization is bad (what you propose yourself) our your exchange of momentum from the outer flow to the near wall is to low, i.e. your eddy viscosity constant is off.
If it is a possibility to change this factor try that or see if there is some kind of wall function converning the near wall eddy viscosity.

Best regards,
Niels

[kumar2]

Hi Neils,

Thanks a lot for your valuable comments. In OpenFoam the Smagorinsky coefficient, Cs is calculated from coefficients ck and ce as Cs=sqrt(ck*sqrt(ck/ce)). In the channelOodles tutorial these are 0.07 and 1.05. thus Cs=0.13. But this is higher than the one used by moin and kim . they used a Cs of 0.065 ( at Rn=13000!). so i reduced my ck to 0.026 ( keeping ce the same) . this gives me a Cs of 0.065.

The results are shown in the figure. when Cs is 0.065 , there is less dissipation , but the slope of the openfoam still is higher than the theoretical log profile. I think my schemes are good because i am using version 1.4.1 , which i believe has bug free time schemes. At this point of time , i wonder if the slope has anything to do with the reynolds number ( based on bulk velocity), because my Rn is about 6600, where the results in the paper by moin and kim is about 13000. although the conference paper data is again at a low Rn. I would greatly appreciate your comments on my new graph.

Thanks again

Best regards

kumar

[ngj]

Hi

Well somewhat better, even though you are now overshooting significantly.
If you estimate the friction factor on a smooth wall, e.g. by using Colebrook and Whites formula, then f=0.0062 for Re=6600 and f=0.0053 for Re=13000, thus your friction factor i 17% to large which gives a friction velocity which is 8% to large. This goes directly into your logarithmic velocity profile.
Thus, try running with Re=13000 and see if it helps.

BTW: How do you include pictures in your posts?

Best regards,

Niels

[kumar2]

Hi Niels,

Thanks again for your valuable comments. Like you have suggested i am going to rerun at Rn=13000.

To add a picture. at the end of your post type

(backwardSlash)image{Text description}. when you actually do it replace backwardSlash with its symbol.

When you finally POST your message, the openfoam site will ask you to upload your picture. and keep the image to less than 50k. you can also find the descrition for uploading images e.t.c by going to the Formatting icon at the left of this web page. From Formatting go to Other Formatting and then Images.

Best regards

Kumar

[lakeat]

Hi Foamers,

what's wrong with the postChannel utility?
It gives nothing now (OpenFOAM-1.5)!! Bug?
......

Daniel

[lakeat]

Ok, I see.

So, why the calculation of R is removed from channelOodles solver, which makes the postChannel utility invalid now?

Daniel

[mattijs]

Hi Daniel,

here are some (untested) fixes to postChannel. Replace postChannel/collapse.H collapse.H and postChannel/readFields.H readFields.H .

[lakeat]

Dear Mattijs,

Thanks a lot.

I saw you had just changed one place - "Umean" to "UMean", right?
But the error message now is still
"cannot open file
blahblahblahblahblahblahblahblahblah channel/*/R".
So, I think the missing of R is the point, I checked the channelOodles.C, and found createAverages.H and calculateAverages.H and writeNAveragingSteps.H, these three including are removed in the new version. So I included them again.

Daniel

[eugene]

There is a good reason createAverages* was removed. The functionality has been replaced by the fieldAverage function object.

[lakeat]

Hallooo, uhh, what's the difference between Umean and UMean?
Ain't Umean and UMean both running average of the velocity field?
why are they different?

[ngj]

Hi Daniel

When you say Umean and UMean, do you mean averages obtained using the averaging procedure in OF-1.4.1 compared to the one calculated using the function object?
I do not know how the averaging procedure looks in OF-1.5, but in 1.4.1, the averaging procedure would only produce correct results as long as you were using a constant time step. Thus if the function object is adjusted to handle variable time steps, and you are using a Courant based time step, then that would explain the difference.

Best regards,

Niels

[lakeat]

Thank you Niels, you know what, I reincluded createAverages.H and calculateAverages.H and writeNAveragingSteps.H these three files to calculate R in OpenFOAM-1.5. But then I found in paraview Umean and UMean are quite different from each other! The difference is from time 1280~1500, UMean almost keep unchanged, but Umean is still changing greatly.

And my wrms/U_bar based on Umean is here which is incorrect, so I have to rethink which one is the true running average of the velocity field.

[lakeat]

I am sorry for the last post, I made a mistake (I deleted uniform/nAveragingSteps.raw, but I forgot to delete uniform/fieldAveragingProperties). In fact, Umean and UMean two files are the same.
Sorry

[ngj]

Hi

Then I would like to emphasize that it does not make sense to use variable time step using the averaging procedure.

Best regards,

Niels