CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Newby with a runaway Courant number (http://www.cfd-online.com/Forums/openfoam-solving/94623-newby-runaway-courant-number.html)

 Phemto November 21, 2011 11:44

Newby with a runaway Courant number

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

 romant November 21, 2011 11:56

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?)

 Phemto November 21, 2011 12:57

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
{
}

fixedWalls
{
}

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.

 Phemto November 21, 2011 17:10

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?

 Phemto November 21, 2011 22:19

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!

 alberto November 22, 2011 04:01

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,

 Phemto November 22, 2011 05:49

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.

 alberto November 22, 2011 16:04

Quote:
 Originally Posted by Phemto (Post 333044) 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,

 Phemto November 27, 2011 17:03

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

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.

 alberto November 28, 2011 03:06

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?

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