I found a problem in the chann
 

I found a problem in the channelOodles tutorial in openFOAM 1.4. The solver runs fine, but the postprocessed data given by postChannel are partially wrong.

As you can see from the plots, the plots of the mean velocity, k, u and uv have the proper shape, but v and w are wrong.

http://www.cfd-online.com/OpenFOAM_D...s/126/4629.jpg

http://www.cfd-online.com/OpenFOAM_D...s/126/4630.jpg

http://www.cfd-online.com/OpenFOAM_D...s/126/4631.jpg

http://www.cfd-online.com/OpenFOAM_D...s/126/4632.jpg

Regards,
Alberto

Sorry, I forgot the plot of uv
 

Sorry, I forgot the plot of uv.

http://www.cfd-online.com/OpenFOAM_D...s/126/4634.jpg

A.

In OpenFOAM-1.4/applications/u
 

In OpenFOAM-1.4/applications/utilities/postProcessing/miscellaneous/postChannel/readFields.H

replace tensor:: with symmTensor:: and recompile postChannel. This is the corrected version:

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif readFields.H

Henry

Thanks a lot Henry! Alberto
 

Thanks a lot Henry!

Alberto

Hello to everyone, how do y
 

Hello to everyone,

how do you guys estimate Re_tau after running few iterations?
u_tau=(nu*(du_x/dy+du_z/dy))^0.53
Do u use postChannel utility? or there is another utility that calculates these values?

Thanks in advance
Hadi

Hi to all, I have modified
 

Hi to all,

I have modified readFields.H, and i compared the rms plots for my channel simulation with DNS, i actually get very close results, for urms, Umean and K but the values of vrms and wrms, are equal to the half of the DNS values.
I don't know if it might be an error in postChannel.

Any help will be appreciated.

Hadi

Hi again, sorry for being ann
 

Hi again,
sorry for being annoying again!

I actually ran periodic channels for Re_tau=395, and Re_tau=180. In openFoam and Fluent.

My U mean profile was good, but rms profiles in openFoam was about 40% off from the DNS values.
In fluent rms profiles was much better!

I was looking to the dimension of R field in the time directory and it is in m/s!?!
I am using version 1.4 is there anything i need to change in the solver?

The graph posted above :uv profile for Re_tau=395 the curve reaches a value of -3e-05, the DNS value is -5.1e-05!

Any help will be appreciated
Hadi

These are Umean and vrms profi
 

These are Umean and vrms profiles, using classic smagorinsky in openFoam and Fluent for Re_tau=395.
In fluent the averages was calculated over a line.
Obviously there is a problem in my rms profiles.
i am using version 1.4,
Could anyone please tell me what might be the problem? is it related to the Reynolds stress tensor as i mentioned above?

Any help will be appreciated
Hadi

http://www.cfd-online.com/OpenFOAM_D...s/126/5752.jpg
http://www.cfd-online.com/OpenFOAM_D...s/126/5753.jpg

Are you running with the Crank
 

Are you running with the Crank-Nicholson ddt scheme?

Hello Henry, Thank you for
 

Hello Henry,

Thank you for your reply.
I am using backward ddt scheme.

The wall shear stress velocity(related to the pressure gradient at the wall) is more underestimated in openFoam than in Fluent.
I think i should normalize the rms of U by u_tau, instead of Ubulk, this should give better results.
right?

hadi

In the publications we have pr
 

In the publications we have produced on the subject, e.g. "Large-eddy Simulation of Turbulent Channel Flows" in Turbulent Shear Flows 11, we normalized with u_tau to be consistent with the DNS data we were comparing with. Are you running both codes with a fixed flow-rate as channelOodles is setup to do?

Yes, i am using the same confi
 

Yes, i am using the same configuration in both calculations, i fixed a constant flow rate, in openFoam, the mean utau is about 10% off from the DNS value for smagorinsky without vanDriest, when using vanDriest utau decreases.
And 2.5 % in fluent(classic smagorinsky).
Do u want me to post the variation of utau in both calculation?

Hadi

How are you calculating u_tau?
 

How are you calculating u_tau?

in openFoam: utau=sqrt(gradp*
 

in openFoam:
utau=sqrt(gradp*delta/rho)
for each time step and then i calculate the mean value during post processing.

I not you are using the backwa
 

I not you are using the backward ddt scheme in version 1.4, have you applied the bug-fix posted on this bugs list? If not I suggest you use the Crank-Nicholson scheme, apply the fix or better still upgrade to version 1.4.1 which includes this and many other corrections and improvements.

I only changed readFields.H in
 

I only changed readFields.H in postChannel, do i have to change anything in the solver? where can i find the bug list for channelOodles?

I will also try Crank-Nicholson scheme.

Thank you so much for you advices.

Cheers,
Hadi

The bug is in the backward dd
 

The bug is in the backward ddt scheme in version 1.4 and the fix has been posted on this bugs list and also fixed in 1.4.1 so the easiest thing for you to do would be to upgrade.

Hello Henry, Thank you for
 

Hello Henry,

Thank you for your advices,

I am using CrankNicholson ddt scheme, waiting for the new version to be installed.
The results didn't converge yet but i have better profiles, i also have better values of u_tau.
When using smagorinsky classic the mean utau value is higher than utau in smagorinsky+vanDriest, since at the wall nusgs is different than zero, so do you think when using utau=sqrt(gradp*delta/rho) in classic smagorinsky i am calculating the real value of utau? or the real value is the one calculated in smagorinsky+vanDriest?
Thanks in advance.
Hadi

http://www.cfd-online.com/OpenFOAM_D...s/126/5799.jpg

oops! Sorry for that!!
 

oops!
Sorry for that!!

utau=sqrt(gradp*delta/rho) sho
 

utau=sqrt(gradp*delta/rho) should be appropriate for channel-flow irrespective of the model used and is the way we calculated utau in the TSF11 paper.

Thank you henry, Is it poss
 

Thank you henry,

Is it possible to have this paper?

Hadi

Hi Hadi, What delta did you
 

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

Hi Hadi, When you used the
 

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

Dear Friends, I have been t
 

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

http://www.cfd-online.com/OpenFOAM_D...s/126/6954.jpg

Hi Kumar It could be intere
 

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

Hi Neils, Thanks a lot for
 

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

Hi Kumar I do not have the
 

Hi Kumar

I do not have the mentioned article, but let us assume that the results in that article is the truthhttp://www.cfd-online.com/OpenFOAM_D...part/happy.gif
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

Hi Neils, Thanks a lot for
 

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

http://www.cfd-online.com/OpenFOAM_D...s/126/7048.jpg

Hi Well somewhat better, ev
 

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

Hi Niels, Thanks again for
 

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

Hi Foamers, what's wrong w
 

Hi Foamers,

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

Daniel

Ok, I see. So, why the calc
 

Ok, I see.

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

Daniel

Hi Daniel, here are some (u
 

Hi Daniel,

here are some (untested) fixes to postChannel. Replace postChannel/collapse.H http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif collapse.H and postChannel/readFields.H http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif readFields.H .

Dear Mattijs, Thanks a lot.
 

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

There is a good reason createA
 

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

Hallooo, uhh, what's the diffe
 

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?

Hi Daniel When you say Umea
 

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

Thank you Niels, you know what
 

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.

http://www.cfd-online.com/OpenFOAM_D...s/126/8478.png

I am sorry for the last post,
 

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

Hi Then I would like to emp
 

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