
[Sponsors] 
Pipeflow with interFoam, kOmegaSST floating point error by initial condition? 

LinkBack  Thread Tools  Search this Thread  Display Modes 
June 28, 2017, 07:27 
Pipeflow with interFoam, kOmegaSST floating point error by initial condition?

#1 
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 7 
Hi all,
I'm quite new to OpenFoam and still in the learning process, so there might be a dumb mistake done but I just can't find it. The case I'm working on is a simple Pipe with two 90 degree shifts in direction which I'm going to compute with interFoam in a komegaSST Model. Later on I'm going to add this case (with mergeMesh and stitchMesh) to another existing case. The intial condition I calculated for nut and omega results always in a floating point error (huge increasing of alpha.water). So I scaled the initial calculated results for nut up and for omega down to let the simulation work. But the big problem is that I need to use the exact results for my master thesis, so I can't really work with those I think. I used the calculation presented in the wiki: nut=c_nu*(k²/epsilon) For my purpose exactly: with I=5% u=0.22179m/s l=0.038*dh=0.038*5=0.19 => k= (3/2)*(0.22179*0.05)²=0.000184466 => epsilon=(0.09)*((0.000184466^(1.5)/0.19)=1.18676E06 => omega=0.000184466^(0.5)/0.19=0.071483201 => nut=0.09*(0.000184466²/2.16671E06)=0.002580544 Is there anything wrong with my calculation? The furthermore: my y+ is around 500 therefore I use Wallfunctions my checkMesh is: Code:
Create time Create polyMesh for time = 0 Time = 0 Mesh stats points: 306028 faces: 885040 internal faces: 836885 cells: 290741 faces per cell: 5.92254 boundary patches: 4 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 259951 prisms: 25807 wedges: 0 pyramids: 0 tet wedges: 20 tetrahedra: 0 polyhedra: 4963 Breakdown of polyhedra by number of faces: faces number of cells 4 728 5 403 6 131 7 2745 8 772 9 80 10 20 12 60 15 24 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. Upper triangular ordering OK. Face vertices OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology defaultFaces 0 0 ok (empty) inlet 434 467 ok (nonclosed singly connected) outlet 491 537 ok (nonclosed singly connected) pipeWall 47230 48035 ok (nonclosed singly connected) Checking geometry... Overall domain bounding box (2.49994 200 2.4982) (2.5 0.0298765 652.498) Mesh (nonempty, nonwedge) directions (1 1 1) Mesh (nonempty) directions (1 1 1) Boundary openness (1.01239e15 5.09219e17 4.32734e17) OK. Max cell openness = 3.25094e16 OK. Max aspect ratio = 8.68508 OK. Minimum face area = 0.00708308. Maximum face area = 0.443196. Face area magnitudes OK. Min volume = 0.00105995. Max volume = 0.112088. Total volume = 16232.1. Cell volumes OK. Mesh nonorthogonality Max: 58.1296 average: 6.74092 Nonorthogonality check OK. Face pyramids OK. Max skewness = 2.12244 OK. Coupled point location match (average 0) OK. Mesh OK. End Thank you for any kind help! 

June 29, 2017, 04:14 

#2 
Senior Member
Alex
Join Date: Jan 2014
Posts: 126
Rep Power: 11 
I can't run your case because of version limitations.
However, I have some questions:  your initial pressure for outlet is 995 Pa. Your internalField is 0 and inlet is zeroGradient. This results in an initially very large gradient. Try using the same value for internalField as you use for outlet, i.e. 995 Pa.  you don't need to specify an epsilon for kOmegaSST  nut is a function of k and omega. It doesn't make sense to fix k, omega and nut at inlet. You can leave the wallFunctions on, but set every other nut to value uniform 0 and type calculated. Rest looks ok. Does this solve your problem? Cheers, Alex 

June 30, 2017, 05:50 

#3  
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 7 
Quote:
Yes you're completely right. I changed it Yes, forgot to delete it after changing from kepsilon to komega  ok changed that too, but actually didn't solved the problem. It just runs when the omega value is e2 in the internalField smaller than my calculated value Yeah I'm working on OpenFoam version 2.4.0 so it's a little bit older... I quick list my files for the 0folder: k Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: 2.4.0   \\ / A nd  Web: www.OpenFOAM.org   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class volScalarField; location "0"; object k; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 2 2 0 0 0 0]; internalField uniform 0.000184466; boundaryField { pipeWall { type kqRWallFunction; value uniform 0.001; } inlet { type fixedValue; value uniform 0.000184466; } outlet { type zeroGradient; } atmosphere { type inletOutlet; inletValue uniform 0.001; value uniform 0.001; } defaultFaces { type zeroGradient; } } Code:
/** C++ **\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: 2.4.0   \\ / A nd  Web: www.OpenFOAM.org   \\/ M anipulation   \**/ FoamFile { version 2.0; format ascii; class volScalarField; location "0"; object omega; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 0 1 0 0 0 0]; internalField uniform 0.0714832;//working with 0.071483201e2 boundaryField { inlet { type fixedValue; value uniform 0.071483201; } outlet { type zeroGradient; } pipeWall { type omegaWallFunction; value uniform 0.071483201; } defaultFaces { type zeroGradient; } } Code:
dimensions [0 2 1 0 0 0 0]; internalField uniform 0; boundaryField { pipeWall { type nutkRoughWallFunction; value uniform 0; Ks uniform 0.001; Cs uniform 0.5; } inlet { type calculated; value uniform 0; } outlet { type calculated; value uniform 0; } atmosphere { type inletOutlet; inletValue uniform 0; value uniform 0; } ".*" { type calculated; value uniform 0; } defaultFaces { type zeroGradient; } } Code:
dimensions [1 1 2 0 0 0 0]; internalField uniform 995.21; boundaryField { pipeWall { type zeroGradient; // type fixedFluxPressure; // value uniform 0; } /* Diffusor { type zeroGradient; // type fixedFluxPressure; // value uniform 0; } */ inlet { type zeroGradient; } outlet { type fixedValue; value uniform 995.21; } atmosphere { type totalPressure; p0 uniform 0; U U; phi phi; rho rho; psi none; gamma 1; value uniform 0; } defaultFaces { type fixedFluxPressure; value uniform 0; } } Code:
dimensions [0 1 1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { pipeWall { type fixedValue; value uniform (0 0 0); } inlet { type fixedValue; value uniform (0 0.22179 0); } outlet { type zeroGradient; } atmosphere { type pressureInletOutletVelocity; value uniform (0 0 0); } defaultFaces { type fixedValue; value uniform (0 0 0); } } Code:
boundaryField { defaultFaces { type zeroGradient; } inlet { type fixedValue; value uniform 1; } outlet { type zeroGradient; } pipeWall { type zeroGradient; } } Edit: Ok got it somehow to run by scaling my velocity up to 10 at the inlet. Is there any chance to get it to run with lower velocity or isn't it possible because there may be high roughness so the water is "stuck" in the pipe? Cheers Oli Last edited by silencebreak; June 30, 2017 at 07:40. 

July 2, 2017, 02:22 

#4 
Senior Member
Alex
Join Date: Jan 2014
Posts: 126
Rep Power: 11 
Hi Oli,
I don't think the water can get stuck at the inlet.  At which iteration does your solver crash?  What is the error message?  Can you get more iterations out of it by lowering the URF? (especially rho)  Can you run the case in laminar? Also, you say that your case blows up because of alpha. Why are you using the vanLeer Scheme for it? I'd recommend using upwind schemes for everything except (rhoPhi,U) for the start. Also try sticking to the regular schemes for grad, laplacian and snGrad at first. From my experience, those "corrections" don't make a case more stable. Cheers, Alex 

July 2, 2017, 09:56 

#5 
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 7 
Hi Alex,
Thanks a lot! well ok That's the error shown. So really high time step continuity errors... So it's the second PIMPLEIteration after the first overall loop Code:
Reading g Calculating field g.h No finite volume options present time step continuity errors : sum local = 2.66909e05, global = 2.66909e05, cumulative = 2.66909e05 DICPCG: Solving for pcorr, Initial residual = 1, Final residual = 26.5344, No Iterations 1001 DICPCG: Solving for pcorr, Initial residual = 0.00866168, Final residual = 0.00224598, No Iterations 1001 DICPCG: Solving for pcorr, Initial residual = 0.00315044, Final residual = 0.00240493, No Iterations 1001 time step continuity errors : sum local = 0.000296733, global = 1.02198e05, cumulative = 3.69107e05 Courant Number mean: 0.0414476 max: 0.306375 Starting time loop Courant Number mean: 0.0414476 max: 0.306375 Interface Courant Number mean: 0 max: 0 deltaT = 0.1 Time = 0.1 PIMPLE: iteration 1 smoothSolver: Solving for alpha.water, Initial residual = 0.00223217, Final residual = 2.81256e13, No Iterations 2 Phase1 volume fraction = 0.994931 Min(alpha.water) = 0 Max(alpha.water) = 1.01124 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase1 volume fraction = 0.994931 Min(alpha.water) = 3.4422e12 Max(alpha.water) = 1.01107 smoothSolver: Solving for alpha.water, Initial residual = 0.00222075, Final residual = 2.77984e13, No Iterations 2 Phase1 volume fraction = 0.994933 Min(alpha.water) = 7.86653e36 Max(alpha.water) = 1.02199 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase1 volume fraction = 0.994933 Min(alpha.water) = 5.57699e12 Max(alpha.water) = 1.02166 smoothSolver: Solving for alpha.water, Initial residual = 0.00220966, Final residual = 2.74783e13, No Iterations 2 Phase1 volume fraction = 0.994935 Min(alpha.water) = 1.31058e32 Max(alpha.water) = 1.03228 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase1 volume fraction = 0.994935 Min(alpha.water) = 9.56679e12 Max(alpha.water) = 1.03178 smoothSolver: Solving for alpha.water, Initial residual = 0.00219878, Final residual = 2.71654e13, No Iterations 2 Phase1 volume fraction = 0.994937 Min(alpha.water) = 5.67318e32 Max(alpha.water) = 1.04211 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase1 volume fraction = 0.994937 Min(alpha.water) = 1.35423e11 Max(alpha.water) = 1.04146 smoothSolver: Solving for alpha.water, Initial residual = 0.00218807, Final residual = 2.68592e13, No Iterations 2 Phase1 volume fraction = 0.994939 Min(alpha.water) = 1.90742e31 Max(alpha.water) = 1.05151 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase1 volume fraction = 0.994939 Min(alpha.water) = 1.72803e11 Max(alpha.water) = 1.0507 DICPCG: Solving for p_rgh, Initial residual = 1, Final residual = 0.0479137, No Iterations 1 DICPCG: Solving for p_rgh, Initial residual = 0.0236374, Final residual = 0.000948872, No Iterations 10 DICPCG: Solving for p_rgh, Initial residual = 0.00121067, Final residual = 0.00455552, No Iterations 1001 time step continuity errors : sum local = 10.171, global = 0.178457, cumulative = 0.17842 DICPCG: Solving for p_rgh, Initial residual = 0.3773, Final residual = 0.0186415, No Iterations 1 DICPCG: Solving for p_rgh, Initial residual = 0.0134827, Final residual = 0.00214595, No Iterations 1001 DICPCG: Solving for p_rgh, Initial residual = 0.00266194, Final residual = 0.00149583, No Iterations 1001 time step continuity errors : sum local = 4.05418, global = 0.143921, cumulative = 0.322341 PIMPLE: iteration 2 #0 Foam::error::printStack(Foam::Ostream&) in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 Foam::symGaussSeidelSmoother::smooth(Foam::word const&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::Field<double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, unsigned char, int) in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #4 Foam::symGaussSeidelSmoother::smooth(Foam::Field<double>&, Foam::Field<double> const&, unsigned char, int) const in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #5 Foam::smoothSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so" #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #8 Foam::fvMatrix<double>::solve() in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #9 ? in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #10 __libc_start_main in "/lib64/libc.so.6" #11 ? in "/projects2/OF_bin/OpenFOAM/OpenFOAM2.4.0/platforms/linux64GccDPOpt/bin/interFoam" Floating point exception (core dumped) Actually the opposite. The time step arises to 258.** but crashes at the same time Nope, still the same error at the same Iteration step But it's absolutely not clear for me why the flow velocity affects whether it crashes or not... For my thesis I want high accurate results but you're right better start with low order numerical schemes. But I tried with your suggestions with upwind instead of vanLeer and the standard discretization, it survived until the beginning of the third iteration but crashed anyway Cheers Oli 

Tags 
initial conditions, interfoam 
Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Maximum number of iterations exceeded chtmultiregionsimpleFoam  Moncef  OpenFOAM Running, Solving & CFD  28  July 13, 2020 14:26 
Segmentation fault when using reactingFOAM for Fluids  Tommy Floessner  OpenFOAM Running, Solving & CFD  4  April 22, 2018 12:30 
Cannot run the code properly: very large time step continuity error  crst15  OpenFOAM Running, Solving & CFD  9  December 14, 2014 18:17 
Moving mesh  Niklas Wikstrom (Wikstrom)  OpenFOAM Running, Solving & CFD  122  June 15, 2014 06:20 
[snappyHexMesh] determining displacement for added points  CFDnewbie147  OpenFOAM Meshing & Mesh Conversion  1  October 22, 2013 09:53 