CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM Running, Solving & CFD

Courant no%23 and sharp corner in 3D

Register Blogs Members List Search Today's Posts Mark Forums Read

LinkBack Thread Tools Display Modes
Old   January 28, 2008, 16:56
Default Is there a way to improve the
Alain Martin
Join Date: Mar 2009
Posts: 40
Rep Power: 10
jam is on a distinguished road
Is there a way to improve the value of the Courant number automatically while running the solver? I am having problems when the fields reached the location of some sharp corner in my domain. The Courant number exponentially grows and the solver stops. It seems that I need a very small delta_t or a very fine mesh to improve the solution. Should I get rid of the sharp corner altogether or is there a better solution?
jam is offline   Reply With Quote

Old   April 15, 2008, 03:28
Default Dear friends, I have the s
Senior Member
Join Date: Mar 2009
Location: Nanjing/Torino, Nanjing/Piemente, China/Italy
Posts: 164
Rep Power: 10
zhoubinwx is on a distinguished road
Send a message via ICQ to zhoubinwx Send a message via MSN to zhoubinwx Send a message via Skype™ to zhoubinwx
Dear friends,

I have the same problem.

My case is a rectangle with the size 430*75 micrometers, inside there are many circles, this is a steady state flow around those many circles.

1. the stop time setting
The inlet velocity is 0.0617m/s, so I set the stop time to be 430*10^(-6)/0.0617*10=0.07;

2. Courant number consideration
Co=deltaT*U/deltax, which should be smaller than 1, in my case the deltaT for the mesh should be deltax=75*10^(-6)/14=5.36*10^(-6)m, deltaT<deltax/U=8.68*10^(-5);
and the minimum circle diameter is 1.17*10^(-6), at last I set the deltaT=1*10^(-5)

After setting others, the simulation stops at Time=0.00017 suddenly, and saying:
Courang Number mean: 5.50717e+104 max: 2.48887e+108

I am confused about this, and also post my problem here, to see if anyboday has some similar problems.

Thank you.

Best regards,

Zhou Bin
zhoubinwx is offline   Reply With Quote

Old   April 15, 2008, 12:56
Default Dear friends, I spend a who
Senior Member
Join Date: Mar 2009
Location: Nanjing/Torino, Nanjing/Piemente, China/Italy
Posts: 164
Rep Power: 10
zhoubinwx is on a distinguished road
Send a message via ICQ to zhoubinwx Send a message via MSN to zhoubinwx Send a message via Skype™ to zhoubinwx
Dear friends,

I spend a whole day to simulate this "simple" problem, but the Courant number increases exponently with time goes by. Here I use icoFoam, because I have calculated the Re is very small.

I have tried simpleFoam, and shut down the turbulent.

I do not know why I have this problem. I will report in the forum when I solve this problem.

Best regards,

Zhou Bin
zhoubinwx is offline   Reply With Quote

Old   April 15, 2008, 23:00
Default I haven't checked recently, bu
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 396
Rep Power: 17
deepsterblue will become famous soon enough
I haven't checked recently, but I'm pretty certain that icoFoam doesn't have adaptive time-stepping based on the Courant number put in. That's easy enough to fix. Use:

# include "setDeltaT.H"

after you evaluate the Courant number, and increment runTime after that within the loop. Take a cue from icoDyMFoam.

Hope this helps.
Sandeep Menon
University of Massachusetts Amherst
deepsterblue is offline   Reply With Quote

Old   April 16, 2008, 12:16
Default I had a similar problem in a v
New Member
Join Date: Mar 2009
Posts: 1
Rep Power: 0
p_murinus is on a distinguished road
I had a similar problem in a very simple Poiseuille flow cell. Turns out my Inlets and Outlets were defined as Patches in the blockMeshDict. Double-check your boundary conditions, there may be some simple error.
p_murinus is offline   Reply With Quote

Old   October 23, 2008, 15:30
Default I think this is a very common
Cem Albukrek
Join Date: Mar 2009
Posts: 52
Rep Power: 10
albcem is on a distinguished road
I think this is a very common problem. I am dealing with the exact same issue; Courant number suddenly growing after a few time steps and the case blowing up.

It becomes a challenge to figure out whether the phenomena is physical, wrong boundary conditions or bad mesh quality related.

To summarize, I am trying to simulate a coarse windsurfer case, for which I am using icoFOAM to keep things simple and making sure I do not violate laminar and incompressibility constraints. The vehicle is inside a rectangular tunnel with blockage of 1%. My boundary conditions are:

INLET: atmospheric velocity profile and zero pressure (normal) gradient

OUTLET: constant atmospheric pressure and zero velocity (normal) gradient

SIDEWALLS: Slip (zero (normal) gradient on velocity and pressure)


FLOOR: No-Slip (0 velocity, zero pressure (normal) gradient)

I am able to pass the CheckMesh with less than 0.1% non-orthogonal triangles with maximum angle at 82 degrees:

Create polyMesh for time = constant

Time = constant

Mesh stats
points: 295150
edges: 1832591
faces: 2971710
internal faces: 2765446
cells: 1434289
boundary patches: 29
point zones: 0
face zones: 20
cell zones: 5

Number of cells of each type:
hexahedra: 0
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 1434289
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
Board 19792 10152 ok (not multiply connected)
Boom 12668 6356 ok (not multiply connected)
Footstrap-FL 759 397 ok (not multiply connected)
Footstrap-FR 693 382 ok (not multiply connected)
Footstrap-RL 761 399 ok (not multiply connected)
Footstrap-RR 727 397 ok (not multiply connected)
Mast 30082 15551 ok (not multiply connected)
MastBase 316 182 ok (not multiply connected)
Sail-Luff 4964 3220 ok (not multiply connected)
Sail-Panel1 6560 3393 ok (not multiply connected)
Sail-Panel2 21116 10776 ok (not multiply connected)
Sail-Panel3 23751 12118 ok (not multiply connected)
Sail-Panel4 18337 9371 ok (not multiply connected)
Sail-Panel5 13876 7109 ok (not multiply connected)
Sail-Panel6 1084 607 ok (not multiply connected)
Sailor 19026 9713 ok (not multiply connected)
Shorts 9593 4873 ok (not multiply connected)
TendonJoint 230 134 ok (not multiply connected)
VR0-Bottom 2552 1408 ok (not multiply connected)
VR1-Bottom 3014 1657 ok (not multiply connected)
VR2-Bottom 2516 1381 ok (not multiply connected)
VR3-Bottom 1306 728 ok (not multiply connected)
VR4-Bottom 4016 2128 ok (not multiply connected)
WT-BasePlate 2839 1610 ok (not multiply connected)
WT-Ceiling 2074 1101 ok (not multiply connected)
WT-Inlet 576 322 ok (not multiply connected)
WT-Outlet 622 345 ok (not multiply connected)
WT-SideWall1 1218 664 ok (not multiply connected)
WT-SideWall2 1196 653 ok (not multiply connected)

Checking geometry...
Domain bounding box: (-46.1548 -73.0691 -3.42362) (68.8019 46.4194 37.9327)
Boundary openness (1.55306e-16 6.01054e-17 1.85018e-15) OK.
Max cell openness = 1.74667e-16 OK.
Max aspect ratio = 22.515 OK.
Minumum face area = 9.07881e-07. Maximum face area = 24.1368. Face area magnitudes OK.
Min volume = 4.31759e-10. Max volume = 31.4018. Total volume = 198531. Cell volumes OK.
Mesh non-orthogonality Max: 82.6972 average: 17.0984
*Number of severely non-orthogonal faces: 577.
Non-orthogonality check OK.
<<Writing 577 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 2.18941 OK.
Min/max edge length = 0.00114348 8.55946 OK.
All angles in faces OK.
All face flatness OK.

Mesh OK.


Given the above I would like to assume my mesh is good and move on to adjusting initial, boundary conditions, discretization schemes or modifying the geometry so that there are no narrow gaps through which the flow can accelerate.

I have gone back as far as the potential solution in the empty tunnel which does not quite resemble the viscous solution. In the viscous solution the athmospheric wind profile spans the whole tunnel, while in the potential solution it is the case at only the inlet. This is strange...

With the windsurfer in the tunnel, I do observe some parts in the geometry (i.e. gap between sailor's feet and footstraps) where flow velocity is high in the potential solution. However I expect the viscous solution to damp these out...

My mission in running this simulation is

1) Proving that a purely open-source mesher, simulator, and post-processor can output relatively complex CFD results.

2) Understanding more of the physics behind the windsurfer and improve the design.

Any experience or input would be of great help. I can supply more information as necessary.

albcem is offline   Reply With Quote

Old   November 18, 2008, 09:21
Default Dear Alain, change your ico
Senior Member
Wolfgang Heydlauff
Join Date: Mar 2009
Location: Germany
Posts: 136
Rep Power: 14
wolle1982 will become famous soon enough
Dear Alain,

change your icoFoam.C like I did with my turbFoam.C and the adjustable timestepControl will be working.

With ongoing calculation the Co-Number will decrease/timestep will increase.
wolle1982 is offline   Reply With Quote


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
meshing sharp edges Ralf Schmidt FLUENT 2 April 6, 2015 09:11
VFE-2 sharp leading edge model Abhishek Main CFD Forum 1 October 23, 2012 03:18
ICEM meshing of sharp corner Sans CFX 3 January 17, 2008 08:36
Flow near sharp corners Harish Main CFD Forum 4 February 21, 2007 22:55
meshing a sharp edge line CFX 2 November 2, 2002 12:19

All times are GMT -4. The time now is 09:34.