CFD Online Discussion Forums

CFD Online Discussion Forums (
-   Main CFD Forum (
-   -   Lack of Recirculation for Lid Driven Cavity Flow (

klw May 17, 2011 19:30

Lack of Recirculation for Lid Driven Cavity Flow
1 Attachment(s)
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!


Thomas_L May 18, 2011 17:23


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.


klw May 18, 2011 17: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.


mettler May 19, 2011 10:03

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

klw May 19, 2011 10: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 11: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 03: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 17:43


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!


palgroth May 21, 2011 04: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)


All times are GMT -4. The time now is 10:57.