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.

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.

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

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.

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.

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.

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.