[RodriguezFatz]

Originally Posted by Chrisstiapis

A problem that I was facing was that although i know the pressure on the outlet cannot use it cause whenever I was putting fixed value or total pressure the solution was becoming divergent

I am sorry, I don't understand this. Could You try other words? Your b.c.s look fine, are all four outlets merged to one outlet called "outlet_extruded"?

Originally Posted by Chrisstiapis

This procedure with the map-fields looks promising although i have never used this function before.

If you create the first (cyclic) case, create it in a way that it's outlet already lies at exactly the same position as the inlet of your current (second) case, same coordinates and same direction. Just as in the picture of the thread I linked above. This works... If you have problems, just write me.

[Chrisstiapis]

In my case the velocity and the pressure at the inlet are both known. (feed is a pump fixed flowrate and pressure)
The problem that when I'm defining the pressure on the inlet my solutions explodes, some insane velocities pop out of the blue.
That's why I have put zerogradient on the inlet.
I think by doing so, the solution is stable but I'm loosing important information.
#As fas as I'm aware in Navier-Stokes equations the pressure gradient drives the flow.#
I tried many combinations of boundary conditions but none of them converges.

[RodriguezFatz]

Ok, I don't think you can set pressure value at inlet and outlet and velocity at the inlet at once. This will end up in over determination.
For incompressible flow, You can
1) set inlet pressure and outlet pressure, velocity gradient at inlet and outlet. This will define the amount of flow through your system by the pressure difference. You can not additionally set the velocity.
2) set outlet (or inlet) pressure and velocity inlet, but with zero gradient for pressure at the other side.

For me case "2" is standard.

Edit: I think I did not understand you correctly. Now: Setting velocity and pressure value at inlet and both zero gradient at outlet should work... I think.

[Chrisstiapis]

Dear Rodriguez,
The simulation managed to converged after 25000 iterations.
The total cummulative error reduced to 10^-9. So for my case at least for now the problem is solved.
Now, I tried just becasuse I'm curious to see what will hapen if i define the pressureand the velocity at the inlet.
As u said it shouldn't be any issues, but I get this error message

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4  Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#8  
 at ??:?
#9  
 at ??:?
#10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11  
 at ??:?
Floating point exception (core dumped)

Weird and Wicked

[RodriguezFatz]

Hmm... I don't understand this. For incompressible flow, the absolute pressure value doesn't mean anything, so it should be completely unimportant where in the domain the pressure is "hard-wired". Can you upload the whole case?

[RodriguezFatz]

Anyway: the four outlets are all outlets to the ambient pressure? Is that correct?

[Chrisstiapis]

The outlets are placed at the bottom of a vessel. The pressure on the outlets in pout=rho*g*h=995*9.81*4.5----> the height of the water level.

I think in this cases the pressure on the outlet and is equal to the hydrostatic pressure.

[RodriguezFatz]

That means, that the pressure at the four outlets is imposed by the ambience, i.e. the height of the water and not by the air flow of your simulation domain? So from the CFD point of view it is a boundary condition? Is that right?

[Chrisstiapis]

Originally Posted by RodriguezFatz

That means, that the pressure at the four outlets is imposed by the ambience, i.e. the height of the water and not by the air flow of your simulation domain? So from the CFD point of view it is a boundary condition? Is that right?

It's true.

I cannot upload the case, there is a limitation on the MB that someone can upload.

http://www.filedropper.com/wholecase

[RodriguezFatz]

Chris, this doesn't work as you think. If you have a fixed outlet pressure as in your case, you can not fix the inlet flow and inlet pressure by a pump. This is not possible. You can either fix the flow and some pressure drop over your domain will develop, or you can fix the pressure drop and some mass-flow will develop. Both doesn't work. This is true for both the experiment and the simulation.

I will have a look at your case anyway.

You are fine. See this post: http://www.cfd-online.com/Forums/ope...tml#post201915

[Chrisstiapis]

Rodriguez, what do you think about the boundary conditions ???
Cause the last thing you told me made me worried.
Are u aware of any similar case ???

[ssss]

Are you using nonOrthogonalCorrectors?

Could you try fixing velocity in outlet and fixing pressure in inlet? Just the opposed as what you are doing. I think there is a problem with your boundary conditions.

[Chrisstiapis]

SSS, No I'm not using non orthogonal correctors, cause mesh non orthogonality is below 60.

I did as u suggested and i get this error message

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#4  Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#5  Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const at ??:?
#6  Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#7  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#8  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#9  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?

[RodriguezFatz]

Chris, your boundary conditions are fine. Just at the outlet for pressure you try to set two different conditions: fixed value and zero gradient. Just delete the line with "zero gradient".
Also, set relTol for all solvers to "0.1"

I recommend to set outlet pressure to zero, because you will be able to see much more in the pictures after the simulation has run. Just bear in mind that this doesn't change the result at all, except that your absolute pressure value changes. Not the relative pressure (i.e. difference) between inlet and outlet.

When you get that error message, do you try to set inlet and outlet pressure? This doesn't work in combination with setting inlet velocity, as I tryed to explain.

[ssss]

I downloaded your testcase and modified the following, for me it's running now:


First of all I added a ";" in the p boundary field, next time try to upload something that works

After that I went to fvSolution and then to SIMPLE dictionary:

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    pRefCell        0;
    pRefValue       49000;
    residualControl
    {
        p               1e-8;
        U               8e-8;
        "(k|epsilon|omega)" 1e-8;
    }
}

simpleFoam asked me to set the pression ref value. You could set your internal pressure to 0 in your boundaryField because you're running an incompressible case because pressure has nothing to do with density thus you're only taking into account pressure variations not absolute values.

I'm using OF230.

[RodriguezFatz]

Originally Posted by ssss

You need to set the pression ref value.

I agree with the other things you wrote, but if he sets the absolute pressure value at the outlet (what he did), this is not necessary. Only if he sets both inlet and outlet pressure to zero gradient.

[ssss]

Originally Posted by RodriguezFatz

I agree with the other things you wrote, but if he sets the absolute pressure value at the outlet (what he did), this is not necessary. Only if he sets both inlet and outlet pressure to zero gradient.

Dear RodriguezFatz,

I didn't know that Openfoam could handle that situacion without setting pRefCell, as I always used 0 anyway. But simpleFoam asked me to write in the fvSolution so I just wrote it and it worked.

I will correct my post.

Thank you very much

[RodriguezFatz]

It can handle it, because by setting the outlet to some fixed value, you already have an absolute reference pressure inside your domain. It just won't use the pRef value in that case.

[gned]

So Chris,
how did you solve your continuity errors on the pipe system ? Which are your suggestions for similar cases?
In your last post you sent your last bcs on U and p but than said, on the contrary, you had to avoid the fixed pressure value at the outlets. So with which bcs you could solve the simulation and with which final fvSchemes of the many suggested? Are the pressures equal for all the outlets ? Your outlet discharge vessel was not pressurized ? Did you measure experimentally these pressures at the outlets to be sure?

[gned]

Hi ssss,
just a question about this old post #32 by you about settling the right bcs. I have to solve something similar to Chris problem. Unfortunately, contrary to him, I don't trust too much the experimental measures they gave to me, in particular about the p at the outlet. Usually, for the bcs classically on this kind of problems are used :
inlet:
p ---> zeroGradient
U ---> flowRateInletVelocity

outlets :

p ----> fixedValue
U ----> zeroGradient

At the inlet, on the contrary, that is at the pump side my confidence on the the right values of p is more.So in your opinion, since I have big problems to get convergence as Chris had, can be the same if I try the other way :
inlet :
p ----> fixedValue
U ----> zeroGradient


outlets :
p ---> zeroGradient
U ---> flowRateInletVelocity
(about this latter, since personally i have only one inlet but 4 different outlets, it's sufficient that I rename with createPatchDict all the outlets under the same boundary patch name and then the flowRate condition is managed right by the solver among the 4 outlets ?)

These conditions I think are numerically wellposed, am I right ?
Why do you think in such problems (flows through orifices/pipes restrictions) we have so many difficulties to converge in OF in general (I found many other people to complain about similar cases issues in the forum indeed)?
thanks a lot