CFD Online Discussion Forums - Is this a plausible incompressible pressure driven flow case?

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Is this a plausible incompressible pressure driven flow case? (https://www.cfd-online.com/Forums/openfoam-solving/176654-plausible-incompressible-pressure-driven-flow-case.html)

yeya	August 23, 2016 16:00

Is this a plausible incompressible pressure driven flow case?

Is this a plausible case?
Say I have a pressure difference driven flow in a cylinder of 200kPa over a distance of 30mm (just simply from the top to the bottom of the cylinder) with a diameter of 2mm, can I use the incompressible solver SIMPLE or is this an compressible case?
Because when I try running the case with simpleFoam i always get a floating point exception (and yes there's nothing set to zero) and the velocity is really high.
If this is a compressible case what solver could I use and why please.

yeya	September 5, 2016 05:30

anyone????

ekrumrick

September 5, 2016 09:45

Hi Yeya,
Is your Mach number lesser than 0.3?
What other information do you have on the case?
Regards,

Ezequiel

Saideep

September 5, 2016 10:17

Hi Yeya;

Compressiblity/ incompressibility depends on what you want to test. Based on the pressure gradient over such short distance will result in extremely high velocities for sure.

Regarding the floating point, it means your code is dividing a variable by 0. Have you changed your code or are you using standard OpenFOAM code?

Check the following thread to know what solver best suits your case study.
http://www.cfd-online.com/Forums/ope...s-icofoam.html

Saideep

yeya	September 5, 2016 17:40

Quote:

Originally Posted by ekrumrick (Post 616637)

Hi Yeya,
Is your Mach number lesser than 0.3?
What other information do you have on the case?
Regards,

Ezequiel

Thanks Ezequiel for your response,

I am not totally sure what the Mach number would be but I am guessing it will be high than 0.3 somewhere in the domain due to the pressure difference over a small space but like I said Im not 100% sure about the physics.

Other information about the case:
I am using a very simple model, just a nozzle shaped as a cylinder where the gas is impinging onto a surface, so the geometry is basically a the mold of a hollow cylinder in a solid box, where the cylinder wall has some thickness.
I have set the boundary conditions such that the velocity at the inlet and outlet is determined by the pressure, and the pressure is fixed.
I am using the realizableKE turbulence model.

do you need more info?

yeya	September 5, 2016 17:48

Quote:

Originally Posted by Saideep (Post 616641)

Hi Yeya;

Compressiblity/ incompressibility depends on what you want to test. Based on the pressure gradient over such short distance will result in extremely high velocities for sure.

Hi Saideep thank you for replying,

I just need to see the velocity over the whole domain, but as you said this would result in large velocity would you recommend a compressible solver?

Quote:

Originally Posted by Saideep (Post 616641)

Hi Yeya;

Regarding the floating point, it means your code is dividing a variable by 0. Have you changed your code or are you using standard OpenFOAM code?

Saideep

I haven't changed any of the code, I am just using the standard OpenFOAM code.
Also, I didn't set anything to zero except 0 velocity at the walls and the placeholder values in the boundary conditions that I have assigned as calculated.

Saideep

September 6, 2016 09:53

Hi Yeya;

I never used Compressible flow cases but as you aren't sure about the result it would be better to go ahead with in-compressible flow solver initially. (Just to make things simple and understand what is happening)

Regarding high velocity:
Probably you could relate your numerical solution with any sort of analytical solutions (if available).

I deal with extremely low flow velocities and use Darcy, Hagen-Poisuielle relations to find velocity based on pressure gradient. However, these relations are valid for laminar flow cases.

Hope this helps;
Saideep

yeya	September 7, 2016 03:54

Hey Saideep!

Quote:

Originally Posted by Saideep (Post 616797)

I never used Compressible flow cases but as you aren't sure about the result it would be better to go ahead with in-compressible flow solver initially. (Just to make things simple and understand what is happening)

I have tried it with incompressible but I keep getting this error, and no I havn't set anything zero,

Code:

Time = 49.5



smoothSolver:  Solving for Ux, Initial residual = 0.44584, Final residual = 0.0287436, No Iterations 15

smoothSolver:  Solving for Uy, Initial residual = 0.421561, Final residual = 0.0224867, No Iterations 16

smoothSolver:  Solving for Uz, Initial residual = 0.410142, Final residual = 0.016996, No Iterations 15

#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 ??:?

#10  Foam::fvMatrix<double>::solve() at ??:?

#11  ? at ??:?

#12  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"

#13  ? at ??:?

Floating point exception (core dumped)

so I thought it might be due to the fact that density might be changing, here I am using simpleFoam and the realiziableKE turbulence model, I want to use the komegaSST but that fails much quicker than this but when I use it for the compressible case with rhoSimpleFoam it runs further tho but still get a floatig point error.

Quote:

Originally Posted by Saideep (Post 616797)

Regarding high velocity:
Probably you could relate your numerical solution with any sort of analytical solutions (if available).

I deal with extremely low flow velocities and use Darcy, Hagen-Poisuielle relations to find velocity based on pressure gradient. However, these relations are valid for laminar flow cases.

The closest I could fnd was a cylinder and using the Hagen-Poisuielle relation I got a velocity in the 1e5 magnitude so it doesn't seem like a good comparison.

Tobi	September 8, 2016 07:25

I just read the thread briefly...

Why you choose the verification & validation subforum? I think your problem would be more related to the solving subforum.

In any case, how did you set up your simple case because the floating point exception you get is obviously related to your set-up. I guess you set fixedValue for p (inlet & outlet) and zeroGradient for U (inlet & outlet).
Did you checked some timesteps ever? If not, do it and maybe you get the point ;)
By the way, if you would get 1000 m/s in the domain - it does not matter in the numerical point of view but the physics behind would be wrong which finally could influence the numerical stability but normally you can solve that. The results would be nonsense.

Good luck.

yeya	September 9, 2016 04:22

Hi Tobias thanks for your reply,

Quote:

Originally Posted by Tobi (Post 617101)

how did you set up your simple case because the floating point exception you get is obviously related to your set-up. I guess you set fixedValue for p (inlet & outlet) and zeroGradient for U (inlet & outlet)

yes your correct about the bc in pressure, this is what I have

Pressure:

Code:

dimensions      [0 2 -2 0 0 0 0];



internalField   uniform 61445;



boundaryField

{

in

{

         type          fixedValue;

    value         uniform 180722;

}

out

{

        type          fixedValue; 

        value        uniform 61039;

    

}

wall

{

        type            zeroGradient;

}

sym

{

       type            symmetryPlane;

}

}

U file:

Code:

dimensions      [0 1 -1 0 0 0 0];



internalField   uniform (0 0 0);



boundaryField

{

in

{

         type            pressureInletUniformVelocity;

        value      uniform (0 0 0);

}

out

{

type            pressureInletOutletVelocity;

        value      uniform (0 0 0);



}

wall

{

        type            fixedValue; 

        value           uniform (0. 0. 0.);

}

sym

{

       type            symmetryPlane;

}

}

I've tried with total pressure at the outlet but the same error.

something also to mention the boundig epsilon value and bounding k is getting really big on the order of 10^20 do you think that might be the problem? i have set a fixed value for the inlet on those and zeroGradient on the outlet and the wall function for the wall.

Quote:

Originally Posted by Tobi (Post 617101)

Did you checked some timesteps ever? If not, do it and maybe you get the point ;)

when viewing the timesteps it looks ok for a couple of timesteps but towards the end it doesn't look good the values increase which seems like to be at a unreasonable rate.

Saideep

September 9, 2016 10:53

Hi Yeya;

When things don't go as expected, decompose your problem into smaller steps. That is, use a smaller pressure gradient and see if the flow physics is comparable to Hagen-Poisuielle relations.

Though it could be laminar flow, if you get the error even here, its easier to know where the problem comes from.

I am not sure about the b.c your using for velocity but as Tobi told,
could you switch to lower pressure gradient (maybe: 1Pa, ofcourse this ultimately depends on your domain size) and zeroGradient for velocity at inlet and outlet and also turn off gravity term.

This exercise should give more information to know what is happening.

Saideep

Tobi	September 11, 2016 04:15

You need total pressure at the inlet, otherwise Our dp will always be the same that will accelerate you fluid till you reach infty...

yeya	September 12, 2016 17:27

Quote:

Originally Posted by Tobi (Post 617426)

You need total pressure at the inlet, otherwise Our dp will always be the same that will accelerate you fluid till you reach infty...

Hi
thanks so much, having total pressure at the inlet worked i had to change the outlet velocity to inletOutlet!

but the problem now is that when I try a compressible case with the same conditions it doesn't work and I get a floating point exception error again.
any suggestions? Am I not suppose to fix any other field?

Tobi	September 13, 2016 03:35

Dear YeYa,

please investigate a bit more time into your questions and provide more information otherwise it is just guessing something. To your question, I am not so familiar with compressible flows but you need to change the total pressure BC. I do not know how you set-up the BC but check out doxygen for the correct use (or go directly to the source-code). In addition as far as I can remember, the BC depend on the problem you are solving. Compressible means that the density is not anymore constant and it is important to specify the correct pressure. Incompressible -> pressure value does not matter, Compressible -> pressure value matters.

yeya	September 14, 2016 17:40

Hey really sorry about that - I'll include more details from now, thanks for helping.

What I meant to say is I took your suggestion and put total pressure for the inlet but that didn't work so i changed the outlet BC for U to inletOutlet and it worked. (see below)

U

Code:

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField

{

in

{

         type            pressureInletVelocity;

        value      uniform (0 0 0);

}

out

{

        type            inletOutlet;

        inletValue      uniform (0 0 0);

        value           $internalField;

}

wall

{

        type            fixedValue; 

        value           uniform (0. 0. 0.);

}

sym

{

       type            symmetryPlane;

}

}

Code:

dimensions      [0 2 -2 0 0 0 0];

internalField   uniform 61445;

boundaryField

{

in

{

        type          totalPressure; 

        p0                uniform 180722;

}

out

{

        type          fixedValue: 

        value                uniform 61039;

        

}

wall

{

        type            zeroGradient;

}

sym

{

       type            symmetryPlane;

}

}

This was for the incompressible case and the velocities yielded to around 700m/s.

Since the speed was so high I am trying to do a compressible case, but I use the same boundary conditions as I did for the incompressible case but I get a floating point error again.
In the compressible case we have to take into account more fields, so my question is, are we not suppose to fix any other BC in the other fields?
For example, suppose I set the temperature boundary condition as fixedValue, would this not make sense?

Tobi	September 14, 2016 17:59

For compressible solvers we only need to solve one equation more (for the energy). This is normally done by using the temperature field and building the enthalpy. Then we solve for the enthalpy, and calculate the density based on the thermodynamic law. Anyway,... if you have a velocity about 700 m/s you should be somehow larger than Ma 1.5, aren´t you? If this is the case, the problem changes and you should not specify the outlet pressure anymore (as far as I can remember).

The totalPressure BC needs to be changed with phi, psi, gamma and rho.
Good luck.

yeya	September 19, 2016 03:45

http://www.cfd-online.com/Forums/<a ...psqwmmuqdr.png

Quote:

Originally Posted by Tobi (Post 617901)

Anyway,... if you have a velocity about 700 m/s you should be somehow larger than Ma 1.5, aren´t you? If this is the case, the problem changes and you should not specify the outlet pressure anymore (as far as I can remember).

The totalPressure BC needs to be changed with phi, psi, gamma and rho.

Why can you not specify the pressure at the outlet anymore?
Because what if the outlet is exposed to the atmosphere but there is an inital pressure at the inlet.

I have attached an image of how the mesh looks like if that helps, the inlet is shaded in orange, and the outlet are the plane faces parallell to the +/-ZY and ZX plane.

http://i1266.photobucket.com/albums/...psqwmmuqdr.png

http://s1266.photobucket.com/user/ye...muqdr.png.html

All times are GMT -4. The time now is 20:47.