CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Running, Solving & CFD (
-   -   Could someone explain this behaviour (

card December 18, 2008 23:59

Hello everyone, I've really
Hello everyone,

I've really struggled on exactly how to post this question, so I'll start from the top. I was simply running a flat plate, incompressible, BL solution because I had extended the plot3dToFoam app to be able to specify more advanced BC's and I was using that as a test case. The simulation was a fairly fine grid with cyclic BC's (i.e. no empty boundaries). The flow was aligned with the x-direction and the y-direction was normal to the plate. I used icoFoam (and yes I know simpleFoam would be fine also, but I wanted to use icoFoam for the moment) and never had the solution converge. The strange part was that the convergence hang up was in the z-velocity residuals where I really wouldn't expect any. The grid is completely orthogonal (yes I ran checkMesh and its perfectly orthogonal), but a few complaints on grid stretching, but the stretching is aligned with the flow. These spurious z-velocities were troublesome, so I decided to set up a very simple uniform velocity test case. A very basic square mesh, using empty BC's for the z-direction. I set a uniform velocity field of 1 in the x-direction and set appropriate BC's (see the attached tarball for the test case). A very simple 20x20 grid, very coarse. . I set the inlet to have a uniform velocity of 1 with a zeroGradient condition on the pressure. The exit had a zeroGradient on velociy and constant pressure 0. The pressure field was initiliazed to 0. The upper and lower BC's had the same conditions as the inlet. So, basically a uniform freestream reproduction test case. What I found was rather surprising. This should have given me absolutely no residuals since the governing equations are satisfied, but there were actually residuals and the solution doesn't converge. How can this be? Please run the attached test case to see this. To further investigate this, I ran foamCalc to calculate the divergence of the velocity field. It's everywhere 0 except for one location, where the value is small, 1.e-14 or so. But it should be identically zero everywhere. As the solution progresses, the divU starts to show small perturbations throughout the flowfield. BTW, this is not a grid resolution issue as this test case I specifically chose the grid such that nodes lie on integer values. Now, here's another fun part. Set the viscosity to zero in the transportProperties file and run it again. The solution behaves as expected, all residuals are zero forever and no change in the flowfield as the initial and BC's satisfy the governing equations. Now, lets have some more fun. Change the grid size slightly by modifying the convertToMeters parameter in the blockMeshDict to 1.01 so that the grid nodes do not lie on integer values and regenerate with blockMesh again. You'll get nodes that have two decimal places like 1.11 and such. Now leave the viscosity set to zero and run icoFoam again. The residuals are back. I've also run with fixed BC's everywhere of U=(1 0 0) and p=0 (yes, I know this is overspecified, but it should satisfy the G.E.'s and give zero fluxes everywhere). To do this, edit the U and p files and change the include to "aux/fixedU" and "aux/fixedp" respectively. Now run the case with the viscosity off still and see that we have residuals. Now, change the grid back to the starting case by setting convertToMeters to 1.0 and regenerating the mesh. Now run icoFoam and the residuals are all zero again!. Better yet, set the viscosity back to 0.00001 again and run it. The residuals are still zero this time!. Can someone please offer an explanation? Many thanks. It seems to me that the divergence is not being calculated properly.

card December 19, 2008 00:02

I forgot to add that I've run
I forgot to add that I've run this on 3 different versions of OpenFOAM. 1.4-dev version from the old svn repo, 1.5 binary from opencfd and 1.5.x from the git repos as of 10/21/08. I also ran it on two different architectures with two different gcc's with the same results.

All the best,


All times are GMT -4. The time now is 19:39.