[jam]

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

[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]

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

[deepsterblue]

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.

[p_murinus]

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.

[albcem]

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: 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.

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 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.

Thanks.

[wolle1982]

Dear Alain,

change your icoFoam.C like I did with my turbFoam.C and the adjustable timestepControl will be working.
See
http://www.cfd-online.com/OpenFOAM_D...tml?1227012935

With ongoing calculation the Co-Number will decrease/timestep will increase.