CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM (http://www.cfd-online.com/Forums/openfoam/)
-   -   Strange boundary behaviour using interFoam (http://www.cfd-online.com/Forums/openfoam/95983-strange-boundary-behaviour-using-interfoam.html)

Andrea_85 January 9, 2012 13:02

Strange boundary behaviour using interFoam
 
2 Attachment(s)
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 06: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 (Post 402475)
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 (Post 402976)
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...


All times are GMT -4. The time now is 01:22.