|January 28, 2008, 16:56||
Is there a way to improve the
Join Date: Mar 2009
Posts: 40Rep Power: 10
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?
|April 15, 2008, 03:28||
Dear friends, I have the s
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.
|April 15, 2008, 12:56||
Dear friends, I spend a who
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.
|April 15, 2008, 23:00||
I haven't checked recently, bu
Join Date: Mar 2009
Location: Amherst, MA
Posts: 392Rep Power: 17
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.
University of Massachusetts Amherst
|April 16, 2008, 12:16||
I had a similar problem in a v
Join Date: Mar 2009
Posts: 1Rep Power: 0
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.
|October 23, 2008, 15:30||
I think this is a very common
Join Date: Mar 2009
Posts: 52Rep Power: 10
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
internal faces: 2765446
boundary patches: 29
point zones: 0
face zones: 20
cell zones: 5
Number of cells of each type:
tet wedges: 0
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)
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.
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.
|November 18, 2008, 09:21||
Dear Alain, change your ico
Join Date: Mar 2009
Posts: 136Rep Power: 14
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.
|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|