|
[Sponsors] |
Pipeflow with interFoam, kOmegaSST floating point error by initial condition? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
June 28, 2017, 08:27 |
Pipeflow with interFoam, kOmegaSST floating point error by initial condition?
|
#1 |
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 9 |
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 k-omegaSST 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.18676E-06 => omega=0.000184466^(0.5)/0.19=0.071483201 => nut=0.09*(0.000184466²/2.16671E-06)=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 (non-closed singly connected) outlet 491 537 ok (non-closed singly connected) pipeWall 47230 48035 ok (non-closed singly connected) Checking geometry... Overall domain bounding box (-2.49994 -200 -2.4982) (2.5 0.0298765 652.498) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Boundary openness (1.01239e-15 -5.09219e-17 -4.32734e-17) OK. Max cell openness = 3.25094e-16 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 non-orthogonality Max: 58.1296 average: 6.74092 Non-orthogonality 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, 05:14 |
|
#2 |
Senior Member
Alex
Join Date: Jan 2014
Posts: 126
Rep Power: 12 |
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, 06:50 |
|
#3 | |
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 9 |
Quote:
-Yes you're completely right. I changed it- -Yes, forgot to delete it after changing from k-epsilon to k-omega - ok changed that too, but actually didn't solved the problem. It just runs when the omega value is e-2 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 0-folder: 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.071483201e-2 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 08:40. |
||
July 2, 2017, 03:22 |
|
#4 |
Senior Member
Alex
Join Date: Jan 2014
Posts: 126
Rep Power: 12 |
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, 10:56 |
|
#5 |
New Member
Oliver K
Join Date: May 2017
Posts: 15
Rep Power: 9 |
Hi Alex,
Thanks a lot! well ok That's the error shown. So really high time step continuity errors... -So it's the second PIMPLE-Iteration after the first overall loop Code:
Reading g Calculating field g.h No finite volume options present time step continuity errors : sum local = 2.66909e-05, global = -2.66909e-05, cumulative = -2.66909e-05 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.02198e-05, cumulative = -3.69107e-05 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.81256e-13, No Iterations 2 Phase-1 volume fraction = 0.994931 Min(alpha.water) = 0 Max(alpha.water) = 1.01124 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase-1 volume fraction = 0.994931 Min(alpha.water) = -3.4422e-12 Max(alpha.water) = 1.01107 smoothSolver: Solving for alpha.water, Initial residual = 0.00222075, Final residual = 2.77984e-13, No Iterations 2 Phase-1 volume fraction = 0.994933 Min(alpha.water) = 7.86653e-36 Max(alpha.water) = 1.02199 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase-1 volume fraction = 0.994933 Min(alpha.water) = -5.57699e-12 Max(alpha.water) = 1.02166 smoothSolver: Solving for alpha.water, Initial residual = 0.00220966, Final residual = 2.74783e-13, No Iterations 2 Phase-1 volume fraction = 0.994935 Min(alpha.water) = 1.31058e-32 Max(alpha.water) = 1.03228 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase-1 volume fraction = 0.994935 Min(alpha.water) = -9.56679e-12 Max(alpha.water) = 1.03178 smoothSolver: Solving for alpha.water, Initial residual = 0.00219878, Final residual = 2.71654e-13, No Iterations 2 Phase-1 volume fraction = 0.994937 Min(alpha.water) = 5.67318e-32 Max(alpha.water) = 1.04211 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase-1 volume fraction = 0.994937 Min(alpha.water) = -1.35423e-11 Max(alpha.water) = 1.04146 smoothSolver: Solving for alpha.water, Initial residual = 0.00218807, Final residual = 2.68592e-13, No Iterations 2 Phase-1 volume fraction = 0.994939 Min(alpha.water) = 1.90742e-31 Max(alpha.water) = 1.05151 MULES: Correcting alpha.water MULES: Correcting alpha.water Phase-1 volume fraction = 0.994939 Min(alpha.water) = -1.72803e-11 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/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.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/OpenFOAM-2.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/OpenFOAM-2.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/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/lib/libfiniteVolume.so" #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #8 Foam::fvMatrix<double>::solve() in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #9 ? in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.4.0/platforms/linux64GccDPOpt/bin/interFoam" #10 __libc_start_main in "/lib64/libc.so.6" #11 ? in "/projects2/OF_bin/OpenFOAM/OpenFOAM-2.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 |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Maximum number of iterations exceeded chtmultiregionsimpleFoam | Moncef | OpenFOAM Running, Solving & CFD | 28 | July 13, 2020 15:26 |
Segmentation fault when using reactingFOAM for Fluids | Tommy Floessner | OpenFOAM Running, Solving & CFD | 4 | April 22, 2018 13:30 |
Cannot run the code properly: very large time step continuity error | crst15 | OpenFOAM Running, Solving & CFD | 9 | December 14, 2014 19:17 |
Moving mesh | Niklas Wikstrom (Wikstrom) | OpenFOAM Running, Solving & CFD | 122 | June 15, 2014 07:20 |
[snappyHexMesh] determining displacement for added points | CFDnewbie147 | OpenFOAM Meshing & Mesh Conversion | 1 | October 22, 2013 10:53 |