Is there a way to improve the
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?
Thanks Alain 
Dear friends,
I have the s
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 
Dear friends,
I spend a who
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 
I haven't checked recently, bu
I haven't checked recently, but I'm pretty certain that icoFoam doesn't have adaptive timestepping 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. 
I had a similar problem in a v
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. Doublecheck your boundary conditions, there may be some simple error.

I think this is a very common
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) CEILING: Slip FLOOR: NoSlip (0 velocity, zero pressure (normal) gradient) I am able to pass the CheckMesh with less than 0.1% nonorthogonal 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 zipup check OK. Face vertices OK. Faceface 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) FootstrapFL 759 397 ok (not multiply connected) FootstrapFR 693 382 ok (not multiply connected) FootstrapRL 761 399 ok (not multiply connected) FootstrapRR 727 397 ok (not multiply connected) Mast 30082 15551 ok (not multiply connected) MastBase 316 182 ok (not multiply connected) SailLuff 4964 3220 ok (not multiply connected) SailPanel1 6560 3393 ok (not multiply connected) SailPanel2 21116 10776 ok (not multiply connected) SailPanel3 23751 12118 ok (not multiply connected) SailPanel4 18337 9371 ok (not multiply connected) SailPanel5 13876 7109 ok (not multiply connected) SailPanel6 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) VR0Bottom 2552 1408 ok (not multiply connected) VR1Bottom 3014 1657 ok (not multiply connected) VR2Bottom 2516 1381 ok (not multiply connected) VR3Bottom 1306 728 ok (not multiply connected) VR4Bottom 4016 2128 ok (not multiply connected) WTBasePlate 2839 1610 ok (not multiply connected) WTCeiling 2074 1101 ok (not multiply connected) WTInlet 576 322 ok (not multiply connected) WTOutlet 622 345 ok (not multiply connected) WTSideWall1 1218 664 ok (not multiply connected) WTSideWall2 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.55306e16 6.01054e17 1.85018e15) OK. Max cell openness = 1.74667e16 OK. Max aspect ratio = 22.515 OK. Minumum face area = 9.07881e07. Maximum face area = 24.1368. Face area magnitudes OK. Min volume = 4.31759e10. Max volume = 31.4018. Total volume = 198531. Cell volumes OK. Mesh nonorthogonality Max: 82.6972 average: 17.0984 *Number of severely nonorthogonal faces: 577. Nonorthogonality check OK. <<Writing 577 nonorthogonal 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. End 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 opensource mesher, simulator, and postprocessor 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. Thanks. 
Dear Alain,
change your ico
Dear Alain,
change your icoFoam.C like I did with my turbFoam.C and the adjustable timestepControl will be working. See http://www.cfdonline.com/OpenFOAM_D...tml?1227012935 With ongoing calculation the CoNumber will decrease/timestep will increase. 
All times are GMT 4. The time now is 18:53. 