channelFoam enforcing u_tau?

kd55 · July 24, 2014, 07:12

Hi there,

I'm running some channel flow simulations, with the ultimate goal of being able to oscillate the top/bottom walls and see a reduction in skin friction.

However, I've been suspicious of my simulations from the start. I have been validating my work initially with plain channel flow (no wall oscillations), and during my mesh independence study, the u_tau and consequently C_f did not change (within reason), no matter coarse the mesh. I think channelFoam has a minimum limit of 1000 cells. That said, although I think the results may be fixed, they are really good results - which is why I was suspicious in the first place.

Anyways, I am just wondering if there is something within the channelFoam solver that is enforcing the frictional velocity/shear stress at the surface.

When I start the oscillations, there is a slight increase in u_tau before it converges to the slightly high value.

I'm using perturbU utility to initialise the turbulence.

Could Ubar (in the transportProperties file) be fixing my results? From my understanding, it is used to calculate some pressure which controlled the flow rate??

Any help or idea's are welcome.

Thanks,

Kit

agustinvo · July 24, 2014, 20:36

Hi,

I have been dealing with a channel flow this year, with a solver similar to channelFoam, but using RAS models.

What do you mean when you say that u_tau and Cf do not change?

Ubar is the mean velocity of the flow in the cross section area of the channel flow. With this parameter and the other transport properties the flow is fixed.

I would say you to take into account the RAS model, but I suppose you are working with LES models.

You can show us also the BC for each variable.

See you!

July 24, 2014, 07:12	channelFoam enforcing u_tau?	#1
kd55 New Member Join Date: Nov 2011 Posts: 22 Rep Power: 15	Hi there, I'm running some channel flow simulations, with the ultimate goal of being able to oscillate the top/bottom walls and see a reduction in skin friction. However, I've been suspicious of my simulations from the start. I have been validating my work initially with plain channel flow (no wall oscillations), and during my mesh independence study, the u_tau and consequently C_f did not change (within reason), no matter coarse the mesh. I think channelFoam has a minimum limit of 1000 cells. That said, although I think the results may be fixed, they are really good results - which is why I was suspicious in the first place. Anyways, I am just wondering if there is something within the channelFoam solver that is enforcing the frictional velocity/shear stress at the surface. When I start the oscillations, there is a slight increase in u_tau before it converges to the slightly high value. I'm using perturbU utility to initialise the turbulence. Could Ubar (in the transportProperties file) be fixing my results? From my understanding, it is used to calculate some pressure which controlled the flow rate?? Any help or idea's are welcome. Thanks, Kit

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
channelFoam	pedroxramos	OpenFOAM Running, Solving & CFD	14	May 8, 2013 07:27
Error in channelFoam Run in parallel	dhruv	OpenFOAM	3	March 2, 2012 06:36
DirectMapped, ChannelFoam	libra	OpenFOAM	2	February 23, 2012 22:24
perturbation in channelFoam?	cheng1988sjtu	OpenFOAM Running, Solving & CFD	5	November 2, 2011 16:36
channelFoam for a 3D pipe	AlmostSurelyRob	OpenFOAM	3	June 24, 2011 14:06

July 24, 2014, 20:36		#2
agustinvo Senior Member Agustín Villa Join Date: Apr 2013 Location: Alcorcón Posts: 314 Rep Power: 15	Hi, I have been dealing with a channel flow this year, with a solver similar to channelFoam, but using RAS models. What do you mean when you say that u_tau and Cf do not change? Ubar is the mean velocity of the flow in the cross section area of the channel flow. With this parameter and the other transport properties the flow is fixed. I would say you to take into account the RAS model, but I suppose you are working with LES models. You can show us also the BC for each variable. See you!