# Newby with a runaway Courant number

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

 November 21, 2011, 11:44 Newby with a runaway Courant number #1 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 Sponsored Links Although I've actually designed advection-based CFD tools, I have almost no experience with the solvers. I set up what I thought was a simple geometry: a straight rectangular channel (using two mirror planes) and an Re on the order of 13. Inflow and outflow are defined by setting a uniform velocity at the plains at either end. All other parameters were copied directly from the lid-driven cavity flow tutorial. It seems that no matter what I do, the Courant number starts off quite small, but then grows exponentially. Reducing the step delays the hard takeoff be does nothing to prevent it. Do I need to just keep lowering deltaT? It already seems like this simple simulation is taking longer than it should, but that's just me seat of the pants analysis. I can post files if necessary. I just set up the account, but I'm not on the VM. Another noob mistake. HELP! and thanks in advance.

 November 21, 2011, 11:56 #2 Senior Member     Roman Thiele Join Date: Aug 2009 Location: London, UK Posts: 368 Rep Power: 14 I am not sure about that, but usually one sets an inflow velocity (velocity driven flow) and pressure to zeroGradient (e.g. simpleFoam) or in the case of a buoyant flow, buoyantPressure (e.g. buoyantBoussinesqSimpleFoam) and a pressure at the outlet. The pressure at the outlet is mostly set to ambient, or in the case of incompressible flow, it can also be set to 0. The velocity at the exit can then be set to pressureInletOutletVelocity, which will give you a velocity based on the pressure when flowing out and if there should be inflow, it will switch to a velocity you define (usually uniform (0 0 0) ) other problems for a runaway courant number can be ill defined meshes. your Reynolds number is very small (almost no flow?) __________________ ~roman

 November 21, 2011, 12:57 #3 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 BIG Thanks for the reply. Maybe I've over-constrained the system. Ok. Here is what I tried. My U file contained these boundary fields. boundaryField { inlet { type fixedValue; value uniform (0 0 0.0069); } fixedWalls { type fixedValue; value uniform (0 0 0); } outlet { type pressureInletOutletVelocity; value uniform (0 0 0); } symmetryplane { type symmetryPlane; } } ...and my p file contained these. boundaryField { inlet { type zeroGradient; } fixedWalls { type zeroGradient; } outlet { type fixedValue; value uniform 1.0; } symmetryplane { type symmetryPlane; } } It seems to go a few more steps, but then the Courant number very quickly goes stratospheric. I've seen pressureInletOutletVelocity used in multiphase systems. I probably should have mentioned that this is a one-phase system, or does that not make a difference here? I don't think the problem is a poorly defined mesh, as right now I just have the one block representing one quarter of the channel (using to symmetry planes). Could that be causing a problem? As for your question of why my Re is so low, I'm trying to model microfluidic systems. The channel is 390um wide by 130um high. Getting the Re to triple digits means things are really flying in there.

 November 21, 2011, 17:10 #4 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 Ok. Reread the last a bit more carefully and I see where I went wrong. There's just one problem for me. For this particular application, I've been asked to specify the flow rate. Is there a boundary condition that allows me to specify the flow rate?

 November 21, 2011, 22:19 #5 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 Success! Although probably not the best way to do it. I used flowRateInletVelocity for both the inlet and outlet velocities (outlet being a negative value, of course) and left the all pressures as zerogradient. It seems to me that setting inflow rate and having a fixed outflow pressure would be a better way to go, but I still haven't found which boundary condition can do that for me. It still requires deltaT of 10^-8 to keep the Courant number below 1, but it stays there now. I guess that partly comes down to the quite high velocities you get in these small channels Thanks Again, and let's here it for well documented code!

 November 22, 2011, 04:01 #6 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,910 Rep Power: 28 If your flow is incompressible, your problem is fully defined when you specify the velocity at one boundary, since you have a simple channel. Fix whatever value of the pressure at the outlet (the value has no influence, since it is just a reference to enforce the continuity). Best, __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats. OpenQBMM - An open-source implementation of quadrature-based moment methods. To obtain more accurate answers, please specify the version of OpenFOAM you are using.

 November 22, 2011, 05:49 #7 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 Thanks for the reply Alberto. You hit the nail on the head. That's exactly what I want to do. I just haven't struck upon the magical incantation to pin the pressure on the outflow plain, but keep velocity floating. I'm sure it's in the set of conditions in the code, but the descriptions are sometimes a bit cryptic for me, or the name is nonobvious and I haven't opened that particular header yet. Down the road, I'll be putting features in the channel, and doing it that way would get rid of the physically unreal return to plug flow that I have now, which means don't have to leave as much space downstream of the features.

November 22, 2011, 16:04
#8
Senior Member

Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,910
Rep Power: 28
Quote:
 Originally Posted by Phemto Thanks for the reply Alberto. You hit the nail on the head. That's exactly what I want to do. I just haven't struck upon the magical incantation to pin the pressure on the outflow plain, but keep velocity floating. I'm sure it's in the set of conditions in the code, but the descriptions are sometimes a bit cryptic for me, or the name is nonobvious and I haven't opened that particular header yet.
Isn't a zeroGradient condition sufficient (if the flow is fully developed it should be) for your U?

Best,
__________________
Alberto Passalacqua

GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats.
OpenQBMM - An open-source implementation of quadrature-based moment methods.

To obtain more accurate answers, please specify the version of OpenFOAM you are using.

 November 27, 2011, 17:03 #9 New Member   Peter Howell Join Date: Nov 2011 Location: Maryland Posts: 6 Rep Power: 7 I would have thought so, but when I try to use zerogradient, I get: --> FOAM FATAL ERROR: Continuity error cannot be removed by adjusting the outflow. Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow. Total flux : 2.08116e-06 Specified mass inflow : 8.7467e-07 Specified mass outflow : 0 Adjustable mass outflow : 4.84641e-27 I'm assuming now that I need to heed the above advice and run potentialFoam first to establish the mass outflow? Unfortunately I'm getting an error from that. --> FOAM FATAL IO ERROR: keyword potentialFlow is undefined in dictionary "/home/phowell/OpenFOAM/phowell-2.0.1/run/mine/toolbox/1chevron/system/fvSolution" file: /home/phowell/OpenFOAM/phowell-2.0.1/run/mine/toolbox/1chevron/system/fvSolution from line 22 to line 42. From function dictionary::subDict(const word& keyword) const in file db/dictionary/dictionary.C at line 461. FOAM exiting For now, I'm back to the manuals.

 November 28, 2011, 03:06 #10 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,910 Rep Power: 28 This usually happens when you specify boundary conditions erroneously, over-constraining the problem. Could you post your case so those who follow the thread can try to fix it? __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats. OpenQBMM - An open-source implementation of quadrature-based moment methods. To obtain more accurate answers, please specify the version of OpenFOAM you are using.

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post vivien OpenFOAM 11 March 9, 2017 04:45 fireman FLUENT 5 July 28, 2016 12:55 kasim CFX 5 March 16, 2008 19:23 msrinath80 OpenFOAM Running, Solving & CFD 9 July 22, 2007 02:58 Kuba FLUENT 0 November 8, 2005 23:44