Strange boundary behaviour using interFoam

Andrea_85 · January 9, 2012, 13:02

Hi all,
I'm facing a strange behaviour using interFoam. I tried these set of boundary conditions:

inlet
p->fixedVale/totalPressure 1.1e5
u->pressureInletOutletVelocity/fluxCorrectedVelocity/zeroGradient

outlet
p->fixedVale/totalPressure 1e5
u->pressureInletOutletVelocity/fluxCorrectedVelocity/zeroGradient

the rest of the domain are walls. The flow is driven by the pressure difference. I tried these BC in every combination but all give the same strange result. After a while the pressure at the inlet becomes not constant and the velocity does the same (see attached pictures). Has anyone else encountered the same problem? How can i solve it?

thanks

andrea

Andrea_85 · January 9, 2012, 13:44

Just another information i forgot: at the inlet i'm injecting fluid one (fixedValue uniform 1 on alpha1 at the inlet)

kumar · January 10, 2012, 03:58

Hello Andrea,
I ran a similar setup when I started my PhD. It was injection of a liquid sheet in to a chamber, where i specified the pressure differences. But I was using OF-1.5 and the boundary conditions that worked for me were:
For pd:

Inlet
inlet
{
type fixedValue;
value uniform 2e5;
}
outlet
{
type fixedValue;
value uniform 0;
}

For U:
{
inlet
{
type pressureInletUniformVelocity;
phi phi;
rho rho;
value uniform (0 0 0);
}
outlet
{
type pressureInletOutletVelocity;
phi phi;
value uniform (0 0 0);
}

and for U at walls i specified fixed value.
for pd at walls i used zerogradient

I am not sure if these bc's still exist in openfoam. But you can try them I hope they will work.

bye
regards
K.Suresh kumar

Andrea_85 · January 10, 2012, 05:25

Great!. It solved the problem.
The only difference with your configuration is that i'm using buoyantPressure for pressure at the wall (or fixedFluxPressure if the contactAngle is specified on alpha1).
Thanks a lot!

andrea

Andrea_85 · January 10, 2012, 09:18

Hi again,
It seems that your suggestion has solved the first problem, but a new one now has appeared (otherwise it was too easy!). I got a floating point error:

Code:

in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[42] #1  Foam::sigFpe::sigFpeHandler(int) in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[43] #1  Foam::sigFpe::sigFpeHandler(int) in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[42] #2   in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[43] #2  ???? in "/lib64/libc.so.6"
[42] #3  Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[42] #4  Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/lib64/libc.so.6"
[43] #3  Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[42] #5  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::PtrList<Foa$
[43] #4  Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[42] #6  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[43] #5  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::PtrList<Foa$
[42] #7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[43] #6  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libfiniteVolume.so"
[42] #8   in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so"
[43] #7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libfiniteVolume.so"
[43] #8  main in "/opt/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccDPOpt/interFoam"
[42] #9  __libc_start_main in "/lib64/libc.so.6"
[42] #10  mainFoam::regIOobject::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/opt/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccDPOpt/inter$
[43] #9  __libc_start_main in "/opt/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccDPOpt/interFoam"
[node03:02989] *** Process received signal ***
[node03:02989] Signal: Floating point exception (8)
[node03:02989] Signal code:  (-6)
[node03:02989] Failing at address: 0x3f500000bad
[node03:02989] [ 0] /lib64/libc.so.6 [0x2b0a630092d0]
[node03:02989] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x2b0a63009265]
[node03:02989] [ 2] /lib64/libc.so.6 [0x2b0a630092d0]
[node03:02989] [ 3] /opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so(_ZNK4Foam3PCG5solveERNS_5FieldIdEERKS2_h+0xe75) [0x2b0a621aa945]
[node03:02989] [ 4] /opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so(_ZNK4Foam10GAMGSolver18solveCoarsestLevelERNS_5FieldIdEERKS2_+0x59f) [0x2b0a621c159f]
[node03:02989] [ 5] /opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so(_ZNK4Foam10GAMGSolver6VcycleERKNS_7PtrListINS_9lduMatrix8smootherEEERNS_5FieldIdEERKS8_S9_S9_S9_RNS1_IS8_EESD_h+0xca1) [0x2b0a621c2e$
[node03:02989] [ 6] /opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libOpenFOAM.so(_ZNK4Foam10GAMGSolver5solveERNS_5FieldIdEERKS2_h+0x48e) [0x2b0a621c44fe]
[node03:02989] [ 7] /opt/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccDPOpt/libfiniteVolume.so(_ZN4Foam8fvMatrixIdE5solveERKNS_10dictionaryE+0x14b) [0x2b0a6166313b]
[node03:02989] [ 8] interFoam [0x425a09]
[node03:02989] [ 9] /lib64/libc.so.6(__libc_start_main+0xf4) [0x2b0a62ff6994]
[node03:02989] [10] interFoam(_ZNK4Foam11regIOobject11writeObjectENS_8IOstream12streamFormatENS1_13versionNumberENS1_15compressionTypeE+0xf1) [0x41e419]
[node03:02989] *** End of error message ***

and here the log file before the crash:

Code:

Courant Number mean: 0.000924621 max: 0.00771491
Interface Courant Number mean: 3.43381e-07 max: 0.0011004
deltaT = 0.000601881
Time = 0.00398119

MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330376  Min(alpha1) = -9.7801e-57  Max(alpha1) = 1.00088
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330378  Min(alpha1) = -9.77621e-57  Max(alpha1) = 1.00169
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330381  Min(alpha1) = -9.77228e-57  Max(alpha1) = 1.0026

GAMG:  Solving for p_rgh, Initial residual = 2.60679e-06, Final residual = 1.76279e-07, No Iterations 1
time step continuity errors : sum local = 1.31676e-07, global = -6.14952e-09, cumulative = -1.4974e-07
GAMG:  Solving for p_rgh, Initial residual = 5.02514e-07, Final residual = 5.02514e-07, No Iterations 0
time step continuity errors : sum local = 3.7534e-07, global = -5.03656e-09, cumulative = -1.54777e-07
GAMG:  Solving for p_rgh, Initial residual = 8.89208e-07, Final residual = 8.89208e-07, No Iterations 0
time step continuity errors : sum local = 6.64173e-07, global = -2.40823e-09, cumulative = -1.57185e-07
ExecutionTime = 117.75 s  ClockTime = 118 s

Courant Number mean: 0.00111767 max: 0.0302757
Interface Courant Number mean: 4.14207e-07 max: 0.0013322
deltaT = 0.000668757
Time = 0.00464995

MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330384  Min(alpha1) = -9.7677e-57  Max(alpha1) = 1.0035
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330387  Min(alpha1) = -9.7626e-57  Max(alpha1) = 1.00543
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330389  Min(alpha1) = -9.75594e-57  Max(alpha1) = 1.00734


GAMG:  Solving for p_rgh, Initial residual = 6.52069e-06, Final residual = 6.13259e-07, No Iterations 1
time step continuity errors : sum local = 5.07027e-07, global = 2.98245e-08, cumulative = -1.27361e-07
GAMG:  Solving for p_rgh, Initial residual = 1.22576e-06, Final residual = 2.2916e-07, No Iterations 1
time step continuity errors : sum local = 1.89455e-07, global = 2.48297e-08, cumulative = -1.02531e-07
GAMG:  Solving for p_rgh, Initial residual = 4.76193e-07, Final residual = 4.76193e-07, No Iterations 0
time step continuity errors : sum local = 3.93663e-07, global = 2.53955e-08, cumulative = -7.71354e-08
ExecutionTime = 120.63 s  ClockTime = 121 s

Courant Number mean: 0.00126773 max: 0.224444
Interface Courant Number mean: 4.68462e-07 max: 0.00151491
deltaT = 0.000764293
Time = 0.00541424

MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330393  Min(alpha1) = -9.74307e-57  Max(alpha1) = 1.00901
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330396  Min(alpha1) = -9.71449e-57  Max(alpha1) = 1.01605
MULES: Solving for alpha1
Liquid phase volume fraction = 0.0330399  Min(alpha1) = -9.6428e-57  Max(alpha1) = 1.02287

It seems that alpha1 becomes unbounded. I'm using the same schems as in the damBreak case, GAMG for pressure and PBiCG for velocity.I tried also to limit the time step (setting a low "maxDeltaT", i'm using adjustableTimeStep) but with no success. What do you think about that?

regards

andrea

vonboett · May 11, 2012, 07:06

in OF 2.1.x a reflection of alpha1 at outlets appeared that wasn't the case in earlier versions. Using PISO instead of PIMPLE solved the problem, maybe this can help here, too.

Fire2fly · January 17, 2013, 05:57

In my case I have also the problem of an unbounded alpha1. But I don't understand what you mean by saying I have to change PIMPLE to PISO, because PIMPLE is basically a combination of the PISO and SIMPLE alghorithm, and in interFoam you cannot change to PISO.

vonboett · January 17, 2013, 09:52

meanwhile I was told that setting zeroGradient for the pressure at the outlet lets both phases pass in interFoam. In OF 2.1 one cant change to PISO as in erlier releases and you are right, the reason must have been somwhere else. Do you use OF 2.1.1? It sais "Boundedness and consistency in the MULES algorithm has been improved for multiphase flows" at the release notes..

Fire2fly · January 17, 2013, 11:47

Yes I use OF 2.1.1. I think it has to do with my buondary conditions. I have a fixed value for the inflow and the outflow of the domain, but also a fixed zero condition for a wall which is perpendicular and attach to the inflow and outflow. I think this imposes high pressure gradients locally and this maybe blows up my calculation.

vonboett · January 20, 2013, 17:10

Quote:

Originally Posted by Fire2fly

Yes I use OF 2.1.1. I think it has to do with my buondary conditions. I have a fixed value for the inflow and the outflow of the domain, but also a fixed zero condition for a wall which is perpendicular and attach to the inflow and outflow. I think this imposes high pressure gradients locally and this maybe blows up my calculation.

Having cells with fixed value inflow at one side and zero velocity at another side is a conflict. Try to fill in a thin slice at your perpedicular walls with flull slip boundary condition, where your wall meets the inflow and outflow. I usually put a blockMesh hex infront of my domain with the inflow at one side and fullslip sidewalls to handle the inflow.

Fire2fly · January 21, 2013, 10:17

Quote:

Originally Posted by vonboett

Having cells with fixed value inflow at one side and zero velocity at another side is a conflict. Try to fill in a thin slice at your perpedicular walls with flull slip boundary condition, where your wall meets the inflow and outflow. I usually put a blockMesh hex infront of my domain with the inflow at one side and fullslip sidewalls to handle the inflow.

Thanks for your replies. Indeed that was also my idea, but initially I made a fault in implementing this. Now I managed to implement it right, but still alpha1 becomes bigger and bigger than 1 ofter some iterations.

vonboett · January 22, 2013, 16:09

ok here is my last idea: Is the inflow area exactly the same as your outflow area, resp. are the inflow and outflow velocities adjusted accordingly up to a high precision? If for example due to rounding errors of the positions of the vertices in your blockMesh or whatever mesh generating file, the size of inflow and outflow does not match the specified inflow and outflow velocity up to a high precision, the continuity of mass could only be provided by changing the alpha1 value as the simulation proceeds...

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Outlet boundary condition for wave flume with interFoam solver	Arnoldinho	OpenFOAM	9	July 10, 2018 06:15
Implementation of boundary conditions for FVM	Tom	Main CFD Forum	7	August 26, 2014 06:58
inlet velocity boundary condition	murali	CFX	5	August 3, 2012 09:56
Strange behaviour because of contact angle (interfoam)	Kim123	OpenFOAM Running, Solving & CFD	0	January 12, 2011 11:16
Boundary conditions?	Tom	Main CFD Forum	0	November 5, 2002 02:54

January 9, 2012, 13:44		#2
Andrea_85 Senior Member Andrea Ferrari Join Date: Dec 2010 Posts: 319 Rep Power: 16	Just another information i forgot: at the inlet i'm injecting fluid one (fixedValue uniform 1 on alpha1 at the inlet)

January 10, 2012, 03:58		#3
kumar Senior Member Suresh kumar Kannan Join Date: Mar 2009 Location: Luxembourg, Luxembourg, Luxembourg Posts: 129 Rep Power: 17	Hello Andrea, I ran a similar setup when I started my PhD. It was injection of a liquid sheet in to a chamber, where i specified the pressure differences. But I was using OF-1.5 and the boundary conditions that worked for me were: For pd: Inlet inlet { type fixedValue; value uniform 2e5; } outlet { type fixedValue; value uniform 0; } For U: { inlet { type pressureInletUniformVelocity; phi phi; rho rho; value uniform (0 0 0); } outlet { type pressureInletOutletVelocity; phi phi; value uniform (0 0 0); } and for U at walls i specified fixed value. for pd at walls i used zerogradient I am not sure if these bc's still exist in openfoam. But you can try them I hope they will work. bye regards K.Suresh kumar

January 10, 2012, 05:25		#4
Andrea_85 Senior Member Andrea Ferrari Join Date: Dec 2010 Posts: 319 Rep Power: 16	Great!. It solved the problem. The only difference with your configuration is that i'm using buoyantPressure for pressure at the wall (or fixedFluxPressure if the contactAngle is specified on alpha1). Thanks a lot! andrea

May 11, 2012, 07:06		#6
vonboett Senior Member Albrecht vBoetticher Join Date: Aug 2010 Location: Zürich, Swizerland Posts: 240 Rep Power: 17	in OF 2.1.x a reflection of alpha1 at outlets appeared that wasn't the case in earlier versions. Using PISO instead of PIMPLE solved the problem, maybe this can help here, too.

January 17, 2013, 05:57		#7
Fire2fly New Member Join Date: Dec 2012 Posts: 4 Rep Power: 13	In my case I have also the problem of an unbounded alpha1. But I don't understand what you mean by saying I have to change PIMPLE to PISO, because PIMPLE is basically a combination of the PISO and SIMPLE alghorithm, and in interFoam you cannot change to PISO.

January 17, 2013, 09:52		#8
vonboett Senior Member Albrecht vBoetticher Join Date: Aug 2010 Location: Zürich, Swizerland Posts: 240 Rep Power: 17	meanwhile I was told that setting zeroGradient for the pressure at the outlet lets both phases pass in interFoam. In OF 2.1 one cant change to PISO as in erlier releases and you are right, the reason must have been somwhere else. Do you use OF 2.1.1? It sais "Boundedness and consistency in the MULES algorithm has been improved for multiphase flows" at the release notes..

January 17, 2013, 11:47		#9
Fire2fly New Member Join Date: Dec 2012 Posts: 4 Rep Power: 13	Yes I use OF 2.1.1. I think it has to do with my buondary conditions. I have a fixed value for the inflow and the outflow of the domain, but also a fixed zero condition for a wall which is perpendicular and attach to the inflow and outflow. I think this imposes high pressure gradients locally and this maybe blows up my calculation.

January 22, 2013, 16:09		#12
vonboett Senior Member Albrecht vBoetticher Join Date: Aug 2010 Location: Zürich, Swizerland Posts: 240 Rep Power: 17	ok here is my last idea: Is the inflow area exactly the same as your outflow area, resp. are the inflow and outflow velocities adjusted accordingly up to a high precision? If for example due to rounding errors of the positions of the vertices in your blockMesh or whatever mesh generating file, the size of inflow and outflow does not match the specified inflow and outflow velocity up to a high precision, the continuity of mass could only be provided by changing the alpha1 value as the simulation proceeds...