Lack of Recirculation for Lid Driven Cavity Flow

klw · May 17, 2011, 20:30

Hi there,

I've been working on a Lid-Driven Cavity flow code in Fortran, and the results I'm getting have me stumped. I would greatly appreciate any help!

I'm using a staggered mesh on the Projection Method, with a CFL of 1.0, Re = 100, and grid of 100x100. I'm getting no recirculation in the lower corners, and the streamlines seem to be "squished" in the y-direction. I don't know if this is characteristic of having bad boundary conditions, a bad algorithm, or not running to the correct timestep.

Boundary conditions implemented are u = 0, v = 0 for all four sides (u = 1.0 for the top wall), and dp/dx = 0 for the side walls and dp/dy = 0 for the top and bottom walls, with p = 0 pinned in the center of the top boundary.

I've attached a picture of my x-velocity (u) with streamlines to show what I'm talking about.

Thank you!

-K

Thomas_L · May 18, 2011, 18:23

Hello,

It seems you have a perfect Stockes Flow without convection. (v.grad(v))
What is your criteria for stopping your calculation? How long do you run your code?

About the no recirculation in the corner, I can notice you use Tecplot, isn't it?
So you use the streamtraces tool. How did you use it?
Because if you use the icon "Add a single or a rake of streamtraces" in the bottom corner, the recirculation will appear.

Thomas

klw · May 18, 2011, 18:40

Hi Thomas,

Thanks for your reply! Yes, I am using TecPlot...I'm very new to it, so I'm still figuring out how to use its features. I just clicked "streamtraces" to add, and drew a line covering the whole plot (it seemed to me that the line dictated where you wanted streamlines to appear, but I could be very wrong). My criteria for stopping the flow is when my residual < 1E-4, where my residual is:

R = max( $|u^{n+1}-u^{n}|$ , $|v^{n+1}-v^{n}|$ )

For my non-dimensionalized time, it's running to t = .225, with a CFL of 1.0, Re = 100, lid velocity U = 1, and box with side dimensions L = 1, and a 150x150 grid.

-K

mettler · May 19, 2011, 11:03

have you tried jumping your mesh size up?..or increasing the Re?

klw · May 19, 2011, 11:55

I've tried jumping the mesh up, but I've seen examples with meshes more coarse than 150x150. I also wanted to match Re to the cases I've seen, so I kept it at 100...however, I have tried to jump Re up, and it doesn't look much different.

mettler · May 19, 2011, 12:12

I got mine to work using the steam function-vorticity. What are your boundary conditions for the corners? One thing I forgot, if I remember correctly (I did this a while ago) was the negative when computing the velocities from the stream function. Another thing you can try is make more stream lines (more dense)..i.e. have a stream line for every .01 change, so you get a whole bunch of them. I am not sure how you do that in your program.

klw · May 20, 2011, 04:34

So after some investigation, it appears as if my method for checking tolerance is insufficient. I forced the algorithm to run for 10x more time steps (despite having no changes in the residuals), and the solution continues to develop! Very odd. Thank you to those who replied with help!

vicarious · May 20, 2011, 18:43

hello,

As one of the guys mentioned try to add more streamline in TECPLOT because at small Re the vortices are tiny.
Also try to increase your mesh up to 250*250 to capture all vortices. I had the same problem with my code which I used vorticity-stream function and at Re=10 & Re=100 there were no vortices at corners while at Re=1000 they were clearly captured.if you simulate caivty in FLUENT you see the vortices in corners at Re=100 are too small if you even use SIMPLEC!

Vicarious

palgroth · May 21, 2011, 05:57

I had the exact same problem a couple of weeks ago. As you, I used projection method. In my case, the problem was related to the advectivce term. First, the advective term was expressed strictly conservative.

d/dx_j (u_i*u_j)

For some reason, I ended up with something similar to your result. Then I changed the expression to a less conservative one, and everything worked just fine.

u_j d/dx_j (u_i)

Pål

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Urgent: Unsteady 3-D supersonic cavity flow	Min-Sung Kang	FLUENT	3	April 6, 2014 10:50
Supersonic Flow over a Cavity (coodles): Maximum Iterations Exceeded	sushant	OpenFOAM Running, Solving & CFD	0	April 9, 2009 03:52
lid driven cavity	ani	Main CFD Forum	3	April 2, 2006 14:27
The 2-D Driven Cavity Problem	debiao	Main CFD Forum	2	January 11, 2006 14:14
boundary condition of wall driven cavity flow	ramin shams	Main CFD Forum	2	June 2, 2004 05:01

May 18, 2011, 18:23		#2
Thomas_L New Member lemee.thomas@gmail.com Join Date: Apr 2011 Posts: 9 Rep Power: 15	Hello, It seems you have a perfect Stockes Flow without convection. (v.grad(v)) What is your criteria for stopping your calculation? How long do you run your code? About the no recirculation in the corner, I can notice you use Tecplot, isn't it? So you use the streamtraces tool. How did you use it? Because if you use the icon "Add a single or a rake of streamtraces" in the bottom corner, the recirculation will appear. Thomas

May 18, 2011, 18:40		#3
klw New Member Kristina Join Date: May 2011 Location: Seattle, WA Posts: 7 Rep Power: 15	Hi Thomas, Thanks for your reply! Yes, I am using TecPlot...I'm very new to it, so I'm still figuring out how to use its features. I just clicked "streamtraces" to add, and drew a line covering the whole plot (it seemed to me that the line dictated where you wanted streamlines to appear, but I could be very wrong). My criteria for stopping the flow is when my residual < 1E-4, where my residual is: R = max( $\|u^{n+1}-u^{n}\|$ , $\|v^{n+1}-v^{n}\|$ ) For my non-dimensionalized time, it's running to t = .225, with a CFL of 1.0, Re = 100, lid velocity U = 1, and box with side dimensions L = 1, and a 150x150 grid. -K

May 19, 2011, 11:03		#4
mettler Senior Member Andrew Join Date: Mar 2009 Location: Washington, DC Posts: 211 Rep Power: 18	have you tried jumping your mesh size up?..or increasing the Re?

May 19, 2011, 11:55		#5
klw New Member Kristina Join Date: May 2011 Location: Seattle, WA Posts: 7 Rep Power: 15	I've tried jumping the mesh up, but I've seen examples with meshes more coarse than 150x150. I also wanted to match Re to the cases I've seen, so I kept it at 100...however, I have tried to jump Re up, and it doesn't look much different.

May 19, 2011, 12:12		#6
mettler Senior Member Andrew Join Date: Mar 2009 Location: Washington, DC Posts: 211 Rep Power: 18	I got mine to work using the steam function-vorticity. What are your boundary conditions for the corners? One thing I forgot, if I remember correctly (I did this a while ago) was the negative when computing the velocities from the stream function. Another thing you can try is make more stream lines (more dense)..i.e. have a stream line for every .01 change, so you get a whole bunch of them. I am not sure how you do that in your program.

May 20, 2011, 04:34		#7
klw New Member Kristina Join Date: May 2011 Location: Seattle, WA Posts: 7 Rep Power: 15	So after some investigation, it appears as if my method for checking tolerance is insufficient. I forced the algorithm to run for 10x more time steps (despite having no changes in the residuals), and the solution continues to develop! Very odd. Thank you to those who replied with help!

May 20, 2011, 18:43		#8
vicarious Member Pedram Mojtabavi Join Date: Apr 2011 Location: Iran Posts: 66 Rep Power: 15	hello, As one of the guys mentioned try to add more streamline in TECPLOT because at small Re the vortices are tiny. Also try to increase your mesh up to 250*250 to capture all vortices. I had the same problem with my code which I used vorticity-stream function and at Re=10 & Re=100 there were no vortices at corners while at Re=1000 they were clearly captured.if you simulate caivty in FLUENT you see the vortices in corners at Re=100 are too small if you even use SIMPLEC! Vicarious

May 21, 2011, 05:57		#9
palgroth New Member Pål Grøthe Sandnes Join Date: Oct 2010 Posts: 13 Rep Power: 16	I had the exact same problem a couple of weeks ago. As you, I used projection method. In my case, the problem was related to the advectivce term. First, the advective term was expressed strictly conservative. d/dx_j (u_i*u_j) For some reason, I ended up with something similar to your result. Then I changed the expression to a less conservative one, and everything worked just fine. u_j d/dx_j (u_i) Pål