
[Sponsors] 
November 22, 2011, 01:16 
convergence problem in using incompressible transient solvers.

#1 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
Dear Foarmers,
Hello, I'd like to simulate the 3D halfwing which is mounted on the symmetry plane. Recently, I applied pisoFoam and pimpleFoam to get the unsteady solutions but the solutions have been diverged. I tried to apply those solvers with lower tolerance criteria, various solver types and schemes but they generally weren't helpful at all. Please give me an advice on using the transient solvers. Here I attached the control, fvSolution and fvSchemes files recently used. controlDict : Code:
1 /** C++ **\ 2  =========   3  \\ / F ield  OpenFOAM: The Open Source CFD Toolbox  4  \\ / O peration  Version: 1.7.1  5  \\ / A nd  Web: www.OpenFOAM.com  6  \\/ M anipulation   7 \**/ 8 FoamFile 9 { 10 version 2.0; 11 format ascii; 12 class dictionary; 13 location "system"; 14 object controlDict; 15 } 16 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // 17 18 //application simpleFoam; 19 application pimpleFoam; 20 //application pisoFoam; 21 22 startFrom latestTime; 23 24 startTime 0; 25 26 stopAt endTime; 27 28 endTime 200; 29 30 deltaT 1e5; 31 32 writeControl timeStep; 33 34 writeInterval 100; 35 36 purgeWrite 0; 37 38 writeFormat ascii; 39 40 writePrecision 6; 41 42 writeCompression uncompressed; 43 44 timeFormat general; 45 46 timePrecision 6; 47 48 runTimeModifiable yes; 49 50 adjustTimeStep yes; 51 52 maxCo 5; 53 54 functions 55 { 56 forces 57 { 58 type forceCoeffs; 59 functionObjectLibs ( "libforces.so" ); 60 outputControl timeStep; 61 outputInterval 1; 62 patches ( wing flap ); 63 rhoName rhoInf; 64 log true; 65 rhoInf 1.225; 66 CofR ( 45.89 0 0 ); 67 liftDir ( 0 1 0 ); 68 dragDir ( 1 0 0 ); 69 pitchAxis ( 0 0 1 ); // PITCH 70 magUInf 2; 71 lRef 53.97; 72 Aref 3006.1; 73 } 74 } 75 76 77 // ************************************************************************* // Code:
1 /** C++ **\ 2  =========   3  \\ / F ield  OpenFOAM: The Open Source CFD Toolbox  4  \\ / O peration  Version: 1.7.1  5  \\ / A nd  Web: www.OpenFOAM.com  6  \\/ M anipulation   7 \**/ 8 FoamFile 9 { 10 version 2.0; 11 format ascii; 12 class dictionary; 13 object fvSolution; 14 } 15 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // 16 17 solvers 18 { 19 p 20 { 21 solver GAMG; 22 tolerance 1e07; 23 relTol 0.001; 24 smoother GaussSeidel; 25 cacheAgglomeration true; 26 nCellsInCoarsestLevel 10; 27 agglomerator faceAreaPair; 28 mergeLevels 1; 29 }; 30 31 pFinal 32 { 33 solver GAMG; 34 tolerance 1e07; 35 relTol 0.001; 36 smoother GaussSeidel; 37 cacheAgglomeration true; 38 nCellsInCoarsestLevel 10; 39 agglomerator faceAreaPair; 40 mergeLevels 1; 41 }; 42 43 U 44 { 45 solver PBiCG; 46 preconditioner DILU; 47 tolerance 1e08; 48 relTol 0; 49 }; 50 51 UFinal 52 { 53 solver PBiCG; 54 preconditioner DILU; 55 tolerance 1e08; 56 relTol 0; 57 }; 58 59 k 60 { 61 solver PBiCG; 62 preconditioner DILU; 63 tolerance 1e08; 64 relTol 0; 65 }; 66 67 omega 68 { 69 solver PBiCG; 70 preconditioner DILU; 71 tolerance 1e08; 72 relTol 0; 73 }; 74 } 75 76 SIMPLE 77 { 78 nNonOrthogonalCorrectors 1; 79 pRefCell 0; 80 pRefValue 0; 81 } 82 83 PISO 84 { 85 nCorrectors 5; 86 nNonOrthogonalCorrectors 0; 87 pRefCell 0; 88 pRefValue 0; 89 } 90 91 PIMPLE 92 { 93 nOuterCorrectors 10; 94 nCorrectors 2; 95 nNonOrthogonalCorrectors 0; 96 pRefCell 0; 97 pRefValue 0; 98 } 99 100 relaxationFactors 101 { 102 U 1; 103 k 1; 104 omega 1; 105 // p 0.01; 106 // U 0.1; 107 // k 0.1; 108 // omega 0.1; 109 } 110 111 // ************************************************************************* // Code:
1 /** C++ **\ 2  =========   3  \\ / F ield  OpenFOAM: The Open Source CFD Toolbox  4  \\ / O peration  Version: 1.7.1  5  \\ / A nd  Web: www.OpenFOAM.com  6  \\/ M anipulation   7 \**/ 8 FoamFile 9 { 10 version 2.0; 11 format ascii; 12 class dictionary; 13 object fvSchemes; 14 } 15 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // 16 17 ddtSchemes 18 { 19 // default steadyState; 20 // default CrankNicholson 0.5; 21 // default backward; 22 default Euler; 23 } 24 25 gradSchemes 26 { 27 default Gauss linear; 28 grad(p) Gauss linear; 29 grad(U) Gauss linear; 30 // grad(U) cellLimited Gauss linear 1; 31 } 32 33 divSchemes 34 { 35 default Gauss upwind; 36 // div(phi,U) Gauss linearUpwindV Gauss linear; 37 // div(phi,k) Gauss linearUpwind Gauss linear; 38 // div(phi,omega) Gauss linearUpwind Gauss linear; 39 div((nuEff*dev(grad(U).T()))) Gauss linear; 40 } 41 42 laplacianSchemes 43 { 44 default Gauss linear corrected; 45 // default Gauss linear limited 0.5; 46 // default Gauss linear limited 0.333; 47 } 48 49 interpolationSchemes 50 { 51 default linear; 52 interpolate(U) linear; 53 } 54 55 snGradSchemes 56 { 57 default corrected; 58 } 59 60 fluxRequired 61 { 62 default no; 63 p; 64 } 65 66 // ************************************************************************* // GeonHong. Last edited by GeonHong; November 22, 2011 at 05:17. 

November 22, 2011, 04:03 

#2 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
Your maximum Courant number is 5, too high. Set it to something less than 1.


November 22, 2011, 05:12 
Courant number

#3 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
Dear alberto,
Thanks for your reply. Of course I tried lower value of Courant number, which was set to be 0.5 or unity. However the problem was the same. Regards, GeonHong. 

November 22, 2011, 08:41 
One possibility

#4 
New Member
Martin Holecek
Join Date: Nov 2011
Location: Prague
Posts: 21
Rep Power: 5 
One possible reason is a mistake in BC's,
To investigate this, I am looking for examples and using their BC's... Or I am looking in the log file what is the diverging variable and trying to find the error there. Another approach is to try to simplify the case. Start from a working example and add feature after feature... and when you will know the step which is causing your troubles you can deal with it. Martin. 

November 23, 2011, 22:06 
dear Holecek

#5 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
Dear Holecek,
Thank you for your reply. I tried other boundary conditions which are used in tutorial cases. Still it doesn't work at all. By the way, what log file should I check? Thank you very much. Regards, GeonHong. 

November 23, 2011, 23:17 

#6 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
Did you check the mesh for problems (checkMesh)?


November 24, 2011, 01:21 
checkMesh

#7 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
Dear Alberto,
Of course I did. However, there is a awkward thing that, High aspect ratio cells found and Failed 1 mesh checks. But I can't find what is problem. The checkMesh result is as below, Code:
/**\  =========    \\ / F ield  OpenFOAM: The Open Source CFD Toolbox   \\ / O peration  Version: 1.7.1   \\ / A nd  Web: www.OpenFOAM.com   \\/ M anipulation   \**/ Build : 1.7.103e7e056c215 Exec : checkMesh Date : Nov 24 2011 Time : 14:03:27 Host : adlc11 PID : 10513 Case : /home/users/kgb/Work/flap/ucav1303/flap10c10b975p nProcs : 1 SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create polyMesh for time = 0 Time = 0 Mesh stats points: 6933336 faces: 20575358 internal faces: 20351362 cells: 6821120 boundary patches: 8 point zones: 0 face zones: 1 cell zones: 1 Overall number of cells of each type: hexahedra: 6821120 prisms: 0 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 0 polyhedra: 0 Checking topology... Boundary definition 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 flap 6172 6174 ok (closed singly connected) bottom 20060 20382 ok (nonclosed singly connected) top 20060 20382 ok (nonclosed singly connected) side 29244 29508 ok (nonclosed singly connected) outflow 36816 37209 ok (nonclosed singly connected) inflow 47200 47637 ok (nonclosed singly connected) symPlane 28860 29223 ok (nonclosed singly connected) wing 35584 35685 ok (nonclosed singly connected) Checking geometry... Overall domain bounding box (247.502 270 0) (900 270 358.535) Mesh (nonempty, nonwedge) directions (1 1 1) Mesh (nonempty) directions (1 1 1) Boundary openness (1.03703e16 1.14641e15 2.58996e15) OK. ***High aspect ratio cells found, Max aspect ratio: 13183.7, number of cells 260418 <<Writing 260418 cells with high aspect ratio to set highAspectRatioCells Minumum face area = 5.15158e07. Maximum face area = 2886.02. Face area magnitudes OK. Min volume = 4.04901e08. Max volume = 71036. Total volume = 1.94209e+08. Cell volumes OK. Mesh nonorthogonality Max: 89.7243 average: 28.048 *Number of severely nonorthogonal faces: 767159. Nonorthogonality check OK. <<Writing 767159 nonorthogonal faces to set nonOrthoFaces Face pyramids OK. Max skewness = 2.69123 OK. Failed 1 mesh checks. End 

November 24, 2011, 01:27 

#8 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
It seems you have 260418 cells with high aspect ratio, and at least one of them has an aspect ratio of 13183.7, which is extremely high.
Code:
***High aspect ratio cells found, Max aspect ratio: 13183.7, number of cells 260418 <<Writing 260418 cells with high aspect ratio to set highAspectRatioCells 

November 24, 2011, 02:27 
checkMesh results

#9 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
Dear Alberto,
Yes, I checked the high aspect ratio cells from the file highAspectRatioCells in constant/polyMesh/sets. What can I do with this cellset? Is there any way to improve this problem? I guess those highaspectratio cells are generated from the cells adjacent to the wall. The wing I want to simulate is tapered, which means that the wing tip has smaller chord length than the root. Furthermore, I generated the structured grid over the wing. Thus the wing has the same number of grid points along the chord at both wing tip and root. This might cause such problems, I guess. Regeneration of the grid is only hope? ToT 

November 24, 2011, 04:29 

#10 
Member
Rob
Join Date: Sep 2011
Posts: 55
Rep Power: 5 

November 24, 2011, 06:16 
about grid problems

#11 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
I've noticed just before that the problems have been occurred far from the wing, not adjacent to the wing.
The problem is that the grid has been generated in structured manner and the grid size along in the downstream was stretched while thin layer of grid for resolving the boundary layer near the wall is maintained. Now I am considering a hybrid grid arrangement : structured near the wall and unstructured at far field. Rob / I used gambit to generate the grid. Now I'd like to try Ansys instead. I have no idea about sHM. What is it? 

November 24, 2011, 06:24 
Fluent

#12 
New Member
GeonHong Kim
Join Date: Feb 2010
Location: Ulsan, Republic of Korea
Posts: 27
Rep Power: 7 
One more thing that I'd like to mention is that I ran the same case(mesh) with the FLUENT but it provided converged transient solution. At least, FLUENT may provide a transient solution though the mesh have extremely high aspect ratio cells which have order of 1e4 as my case.
From following thread, Mads Reck also referred that aspect ratios of more than 1000 is by no means insane  we have it in airfoil aerodynamics all the time  and on wind turbine blades. Aspect ratios of 1e5 or even higher is usual business when you want to have a first cell height of around 1e6 chordLengths. results with checkMesh...please comment I hope to resolve this problem as soon as possible. 

November 24, 2011, 06:39 

#13  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 369
Rep Power: 10 
Quote:
Fluent starccm+ etc apply lots of tricks (trade secrets) to keep solver stable. The main difficulty with high respect ratio is that it makes pressure correction equation very difficult to converge, which could make solver unstable. OpenFOAM does not apply such tricks so things should be more difficult with it. For this reason you would need good quality meshes with openFOAM. 

November 24, 2011, 06:48 

#14 
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7 
Hi,
You have some cells with high nonorthogonality (90 starts to be a high value imo). You should used "limited 0,333" schemes and not "corrected" schemes (snGrad). I don't know if it would solve your problem, but it should be a start. Aurelien 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
the problem of my transient simulation "Floating point exception: Overflow "  alloveyou  CFX  15  November 22, 2012 12:14 
Transient axial rotor/stator convergence issue?  Nicola Viscanti  CFX  3  March 17, 2010 05:15 
Continuity eq convergence problem  carno  FLUENT  4  February 8, 2008 05:04 
convergence problem  Trushar  Phoenics  5  August 27, 2002 23:40 
convergence problem with SIMPLER  NURAY KAYAKOL  Main CFD Forum  1  February 24, 1999 14:43 