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

HELP! and thanks in advance.

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

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.

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?

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!

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,

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.

Isn't a zeroGradient condition sufficient (if the flow is fully developed it should be) for your U?

Best,

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.

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?