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.