[marco.müller]

Hi,

I wonder if there is no way to define a "real" (fixed) pressure drop in OpenFOAM?! Coming from another CFD code, I thought this was quite trivial ...

Using static pressure (fixedValue) at in-/outlet ends up in no converging flux, using totalPressure (as suggested) is never independent of flux and thus variable. Also the common bc guide is confusing, as it suggests that in- and outflow is treated the same way for totalPressure bc.

Is there no clever solution aside from the iterative one?

Thanks
Marco

[sqek]

Not entirely sure exactly what you're asking for, but I'm reading it as "make two patches have a fixed jump in pressure between them"
For that, there's a uniformJump or uniformJumpAMI, based off of cyclic or cyclicAMI - you set two patches to be cyclicly coupled, and specify a jump between them, and it will adjust both values to get the right jump/drop between them. This doesn't work if they're very different areas, or aren't coupled for the other flow variables, however.

If you do need to set the values of other fields, you'll probably need to build your own bc with a base of outletMappedUniformInletFvPatchField (which takes the average value of an outlet and sets it to an inlet), and add a jump value within updateCoeffs - that will let you specify the mean pressure for your inlet as jump+(mean outlet pressure)

And with the common BC guide: if there's an outflow at a totalPressureBC, it just returns the specified pressure, if there's an inflow it subtracts the velocity change from the specified pressure - so it can be used as a constant pressure outflow, and behaves nicely if you get reversed flow from unsteadiness / starting transients.

[marco.müller]

Hi,

no, I dont want to couple inlet and outlet. I just want to specify a constant pressure delta between inlet and outlet, lets say 1 bar static pressure inlet and 0 bar static pressure outlet to calculate a flow coefficient. Incompressible. I dont think that this task is too much rocket science or is it?

Marco

[sqek]

Setting constant pressures should work then, but 1 bar difference is a lot - if that's what you've been using, the non-convergence might just be because your velocities are going unphysically high

Also what deltaT are you using / what CFL number are you getting? If you're using PISO, CFL should be <1, if you're using PIMPLE then make sure, if CFL>>1, that the under-relaxation factors are low enough and that nOuterCorrectors is big enough that it's actually converging each timestep

Try using fixedValue with some real values that are the right estimated order-of-magnitude (say 10% of the rho/2*V^2 dynamic pressure, so ~600Pa if you expect velocities of around 100m/s)

In my experience, openfoam works best when its simulating something that could physically exist, and if you try to non-dimensionalise and feed it non-physical values the solvers (and default coefficients in $FOAM_ETC) aren't optimised for that and don't perform so well, so specifying a 1 bar pressure difference across an incompressible domain, which could give velocities of over 400m/s (so supersonic), is likely to misbehave.

[marco.müller]

stop stop stop! Who told you of pimple and temperature and gas?

I'm just talking of incompressible flow and for my pressure example: water.

I can't believe no one has faced this issue before?!

Thanks!

[sqek]

Ah that makes more sense

Just checking, do you know that openfoam uses kinematic pressure (p/rho) for incompressible solvers? So for 1e5Pa and water at 1000kg/m3, you'd set 100, not 1e5

Which solver are you using?
Setting fixedValue for pressure and pressureInletOutletVelocity or zeroGradient for velocity at both inlet and outlet should work, if everything's set right in controlDict/fvSchemes/fvSolution, the mesh is okay, and there's enough viscous/turbulent loss, or decrease in flow area, or rising against gravity, to drop 1 bar of pressure across the domain without the velocities going ridiculously high

(for reference, modifying $FOAM_TUTORIALS/incompressible/icoFoam/elbow so that inlet-5 has fixedValue for p at 1, inlet-6 has fixedValue for p at 10, both have zeroGradient for velocity, and deltaT is reduced to 0.01, runs fine - openfoam can do a flow with inlet/outlet pressure specified if the numbers/mesh/timestep/etc are right)

[marco.müller]

I knew that and do not see an issue with the absolute pressure drop value. I see the same behaviour at 1 Pa.

I'm using simpleFoam.

In which elbow tutorial do you see a pressure driven flow? Any I find is flow driven.

[sqek]

Do you have any screenshots of it not converging with two fixedValue pressures, that might help figure out why?
And is it crashing / diverging and getting floating point errors, or is it running fine but not converging? Turning the under-relaxation factors down will make it less likely to crash/diverge, but will need more timesteps to converge, that might be worth a try (sorry I've been talking about timesteps and cfl numbers, I'm too used to unsteady stuff - under-relaxation is the main adjustment for simple instead)

There's not a pressure driven flow in the tutorials (that I could find) - I modified one to be pressure driven, just to check that it could be made to converge, although that was with icofoam
I'm not that familiar with simplefoam, I've always been using unsteady solvers with piso/pimple rather than simple, which have different things to tweak

[DevilX]

Originally Posted by marco.müller

I knew that and do not see an issue with the absolute pressure drop value. I see the same behaviour at 1 Pa.

I'm using simpleFoam.

In which elbow tutorial do you see a pressure driven flow? Any I find is flow driven.

I am working on compressor simulation and i have cases for simplefoam which runs at a difference of 20 bar, also some simulation with rhoSimpleFoam (compressible) with CO2 as fluid up to 15 bar and it works fine.


So it´r absolutely possible and most likely your BC´s are incorrect. Do you want to show them?

[marco.müller]

sure:

P:

IN
{
type fixedValue;
value uniform 1e2;
}

OUT
{
type totalPressure;
p0 uniform 0;
value uniform 0;
}

U:

IN
{
type zeroGradient;
}

OUT
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}


Let me add that I've had some success with blending total and static pressure at the inlet, but still it looks like in the attached screenshot (in this case an air example with lower pressure), showing the divergence in the end:

IN
{
type codedFixedValue;
value $internalField;

name totalStaticPressureBlend;

code
#{

#include "$FOAM_CASE/constant/pCalc"

const scalar t = this->db().time().value();
const fvPatchVectorField& UP = patch().lookupPatchField<volVectorField, vector>("U");
const scalar tEnd = this->db().time().endTime().value();

if (t < tEnd) {
operator==( pP - 0.5*magSqr(UP)*(1-sin(M_PI*t/(2*tEnd))) );
} else {
operator==( pP );
}

#};
}

[DevilX]

You are using simpleFoam, right? Then you have to use the pressure/Density instead of real pressure values.


Also, you need to specify the totalPressure at the Inlet, and fixedValue at the Outlet. For Inlet with respect to U, use pressureInletvelocity and Outlet pressureInletOutlet or just InletOutlet with values of 0 everywhere.

[marco.müller]

@DevilX: please read my former posts. totalPressure is exactly what I need to avoid since I have no clue about velocities before running the simulation.

I want to specify a STATIC pressure delta.

[Tobermory]

Marco

for incompressible flows, specifying static pressure at inlet and outlet is expected to lead to poor convergence, as noted in Ferziger & Peric's book. This webpage gives a nice summary of the performance of typical BC configurations:
https://www.openfoam.com/documentati...ssure-velocity.

As for your case, I understand why you don't want to use a totalPressure BC ... but you could try an semi-iterative approach to zero in on the required Ptot_inlet. ie run the case for a range of Ptot_inlet values, measure the dP_static and interpolate to get the setup that you want. Or you could try code up some scripting to converge in on the value. Messy, I know.

Good luck.

[sqek]

FixedValue for inlet and outlet can work (with zeroGradient or pressureInletvelocity for velocity), but as others have said it is tricky in terms of convergence - the solver has to find a velocity field that gives enough pressure loss from turbulence/viscosity/flow separation, and there's a long feedback loop between velocity changing, losses increasing, and pressure being correct

I'd suggest switching to an unsteady solver, where the weird transients you'll get as the flow accelerates/decelerates from your starting value can at least be more physically realistic - it'll still stabilise eventually, but will be able to do more, smaller, iterations beforehand (less change between each iteration, so less chance of a big numerical spike that starts to cause errors), so will be more stable

A solver like pimpleFoam, with low enough under relaxation factors and using adjustable timestep with a low enough maxCo in controlDict, should be able to get through any horrible starting transient or set of boundary conditions you throw at it, although it will take a long time to run, and eventually you'll get a steady velocity field (if your case is actually steady in reality, otherwise you'll get vortex shedding or something)

Otherwise, if you're trying to calculate a pressure loss coefficient / flow coefficient, set it up with a fixed velocity inlet / fixed pressure outlet, and read off the pressure, that'll take much less time to run

Also I notice you're using totalPressure for the outlet, any particular reason for that?
Also using pressureInletOutletVelocity for the inlet might help stabilise things slightly - it's like zeroGradient for the normal velocity, but fixes the tangential velocity

[marco.müller]

Guys, thanks for confirming my finding that the static pressure delta is not or not easily possible. Honestly, I've been a little spoiled using a commercial cfd code for many years where this bc combination was no problem. Dont get me wrong, I wouldnt want to go back ...

I'm using totalPressure at the outlet since it acts like static pressure (if no reverse flow occurs) and provides more stability (if reverse flow occurs).

That fact that it normally acts like a static pressure condition would be my suggestion for improvement to the website mentioned, where it is described as physical total pressure.