|
[Sponsors] |
January 3, 2013, 11:02 |
Hex and Tet meshes - simplefoam comparison
|
#1 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
Hi everybody,
Since I need to use the dynamicTopoFvMesh class I'm trying to understand how my sims (already run with hex meshes) performs using Tet meshes. I started studying the flow rate of a custom valve. Enclosed you can see the same geometry meshed with SHM and with Netgen, togheter with their checkmesh results. Some notes: - Same pressure driven BC for both the cases. - Same turbolence model setup (komegaSST). - Same fvscheme and fvsolution. This is the log file of the flow rate using hex meshes: Code:
# Time inlet outlet 1 -5.700601 5.700579 2 -3.79034 3.790358 3 -4.903445 4.903438 4 -5.377026 5.377034 5 -5.704897 5.704898 6 -5.944335 5.944333 7 -6.119664 6.119663 8 -6.220943 6.220941 9 -6.256514 6.256513 10 -6.250962 6.250963 11 -6.218107 6.218109 12 -6.161133 6.161132 13 -6.088814 6.088814 14 -6.00451 6.004513 15 -5.912531 5.912534 16 -5.815976 5.815976 17 -5.716687 5.716688 18 -5.6167 5.6167 19 -5.517849 5.51785 20 -5.422765 5.422765 21 -5.333158 5.333159 22 -5.250153 5.250153 23 -5.173377 5.173377 24 -5.102728 5.102728 25 -5.037989 5.037989 26 -4.978615 4.978616 27 -4.924211 4.924208 28 -4.874001 4.874 29 -4.827512 4.827511 30 -4.784434 4.784432 31 -4.744479 4.744479 32 -4.708216 4.708216 33 -4.675977 4.675978 34 -4.647641 4.647642 35 -4.622598 4.622598 36 -4.600458 4.600458 37 -4.580474 4.580475 38 -4.562082 4.562083 39 -4.544581 4.54458 40 -4.527438 4.52744 41 -4.510434 4.510434 42 -4.493563 4.493563 43 -4.476761 4.476761 44 -4.460181 4.460181 45 -4.443663 4.443663 46 -4.426965 4.426965 47 -4.410062 4.410062 48 -4.39336 4.39336 49 -4.376991 4.376991 .... 2627 -4.27264 4.270662 2628 -4.272626 4.27058 2629 -4.272489 4.270488 2630 -4.272234 4.270317 2631 -4.271874 4.270348 2632 -4.271439 4.270732 2633 -4.27099 4.271581 2634 -4.270574 4.272077 2635 -4.270118 4.271661 Code:
# Time inlet outlet 1 -172.0041 21.71271 2 -29.95186 1.310735 3 -57.05148 23.14831 4 -50.40974 30.45741 5 -42.4858 35.18858 6 -10.63777 21.76366 7 -14.34278 7.928121 8 -19.71502 2.089407 9 -20.83303 9.133087 10 -12.97812 21.45 11 -15.64673 24.9519 12 -18.66453 22.21093 13 -20.08745 5.498206 14 -10.07858 0.3255894 15 -8.387256 3.84717 16 -2.87546 10.25943 17 -4.728935 13.8913 18 -1.959338 13.97463 19 -9.568247 5.668299 20 -7.270501 3.24852 21 -6.705826 5.219731 22 -4.514791 7.281349 23 -6.902184 8.871348 24 -5.602596 7.402167 25 -8.852266 4.557721 26 -6.024786 9.46239 27 -5.604201 6.377496 28 -3.582253 7.762387 29 -4.761439 7.010344 30 -5.44479 5.005502 31 -6.136755 4.06424 32 -4.496904 4.433816 33 -4.910032 5.501521 34 -5.057533 5.617444 35 -5.251011 5.396437 36 -3.316635 4.600008 37 -5.171873 4.411376 38 -5.573408 4.209184 39 -4.3302 4.705713 40 -4.163483 4.676618 41 -2.761881 4.432551 42 -3.619489 3.871926 43 -4.572584 3.528158 44 -3.58269 3.626229 45 -3.723246 3.58942 46 -3.62441 3.603673 47 -3.386411 3.532791 48 -3.105231 3.406442 49 -2.682748 3.179411 50 -2.841984 2.989721 51 -2.799791 2.711039 52 -2.827969 2.447284 53 -2.735649 2.314938 54 -2.527999 2.362736 55 -2.452254 2.342192 56 -2.333465 2.369357 57 -2.174707 2.385321 58 -2.045561 2.35066 59 -2.002889 2.26217 60 -1.992403 2.144051 61 -1.961413 2.003014 62 -1.941028 1.842707 63 -1.969635 1.706767 64 -1.976639 1.629558 65 -1.983343 1.656954 66 -2.024261 1.763623 67 -2.057045 1.869765 68 -2.08375 1.999511 69 -2.208145 2.08836 70 -1.955683 2.163669 71 -2.044087 2.2096 72 -2.084881 2.236304 73 -2.368958 2.315571 74 -2.469138 2.371803 75 -2.61045 2.457574 76 -2.798879 2.556751 77 -3.012586 2.678196 78 -3.194521 2.811004 79 -3.356413 2.947216 80 -3.43074 3.077914 81 -3.443503 3.194778 82 -3.465136 3.298215 83 -3.524945 3.395603 84 -3.6387 3.500317 85 -3.807765 3.615832 .... 563 -4.316257 4.31451 564 -4.315974 4.31457 565 -4.316129 4.3145 566 -4.316908 4.31411 567 -4.316524 4.314286 568 -4.316411 4.314671 569 -4.316268 4.314813 570 -4.316568 4.314814 571 -4.316601 4.314811 572 -4.317013 4.314497 Even if the converging result seems good I've got some questions: - The hex mesh case is converging not only faster... but better. Is it possible that mass conservation law is not respected in the first iterations of the tet mesh case ? See differences in the inlet/outlet flow rates... - I used the same fvschemes and fvsolution for both the meshes. I tried other settings (see http://www.cfd-online.com/Forums/ope...tml#post257294) but with more instabilities during the first iterations. Below are my settings: fvSchemes: Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.0.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSchemes; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // ddtSchemes { //default Euler; default steadyState; } gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,U) Gauss linearUpwindV grad(U); div(phi,k) Gauss upwind; div(phi,omega) Gauss upwind; div((nuEff*dev(T(grad(U))))) Gauss linear; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; p; } // ************************************************************************* // Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.0.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object fvSolution; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solvers { p { solver GAMG; tolerance 1e-8; relTol 0.01; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 20; mergeLevels 2; } pFinal { solver GAMG; tolerance 1e-8; relTol 0; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; } U { solver smoothSolver; smoother GaussSeidel; tolerance 1e-8; relTol 0.05; nSweeps 1; } k { solver smoothSolver; smoother GaussSeidel; tolerance 1e-9; relTol 0.01; nSweeps 1; } omega { solver smoothSolver; smoother GaussSeidel; tolerance 1e-9; relTol 0.01; nSweeps 1; } } SIMPLE { nNonOrthogonalCorrectors 1; pRefCell 0; pRefValue 0; residualControl { p 1e-5; U 1e-5; nuTilda 1e-5; } } potentialFlow { nNonOrthogonalCorrectors 10; } relaxationFactors { p 0.5; U 0.7; k 0.6; omega 0.6; } PISO { nCorrectors 2; nNonOrthogonalCorrectors 0; pRefCell 0; pRefValue 0; } cache { grad(U); } // ************************************************************************* // Personally I'm not unsatisfied of the comparison. There is about 1 % difference in the flow rates results and the tet sim is still running. I'm just worrying because I need to use tet meshes with dynamicTopoFvMesh in order to simulate the equivalent of a check valve: an object immersed in a pushing fluid is going to close the outlet... it's one of the worst setup I think... Above all, here http://www.google.it/url?sa=t&rct=j&...55534169,d.bGE it says that "Crushing cell is not supported (Example: complete valve closure for cylinder simulations)" but it was one and half years ago...what about now ? More: Looking in the forum it seems that tet meshes are a little delicate to work with... is there anyone who use dynamicTopoFvMesh on real cases ? I'm sorry for the long thread. Any comment ?
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
January 3, 2013, 11:36 |
|
#2 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Daniele,
I'm not surprised to see that Hex meshes gives better results - they inherently have less non-orthogonality. You'll have to play with the nNonOrthogonalCorrectors with tets and see if that helps. Also, you have a gradient scheme that isn't really the best - try leastSquares. You could also try Hrv's reconCentral schemes from 1.6-ext and see if that changes things. |
|
January 3, 2013, 12:01 |
|
#3 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
Thanks for the suggestions. Unfortunately I cannot use the ext version, but I'll try others schemes. Any news regarding the crushing cells limitation ?
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
January 3, 2013, 12:08 |
|
#4 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Well, I suppose you could compile the sources for reconCentral in 2.1.x - I don't think there's anything in there specific to 1.6-ext.
The closest thing I can see in OpenFOAM to complete valve closure is either by changing a GGI / AMI patch at run-time to wall - which probably has adverse stability issues where you'll have to either under-relax or reduce the time-step. Or possibly by switching cells off by marking cells in a specific zone and deactivating it. You could try playing around with porous zones too... |
|
January 3, 2013, 12:10 |
|
#5 |
Senior Member
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25 |
Hello,
I use Tetrahedral meshes quite often (well... almost always), and as you have seen, the convergence of a simulation when using Tet meshes is in most cases not as good as for the same system with a hex dominant mesh. However, I would suggest that you try the following in addition to the suggestions by Sandeep: 1. As Sandeep mentioned.... for Tet meshes, non-orthogonal correctors are almost always a requirement. I use 2 non-orthogonal correctors, and it works quite well. 2. I noticed that your relaxation factors are quite high.... You could try with lower values to start of with (say for the first 250 - 300 iterations). Again... a suggested value is: 0.3 for all the variables. The results from Checkmesh seem to be quite ok for the Tet mesh, and I dont think you can get too much better than that.... as far as non-orthogonality goes. You could try one more thing..... In netgen, in the meshing options, you can choose the number of optimisation steps for the surface and volume mesh generation...... Set the Surface Mesh optimisation to around 15 steps, and the volume mesh optimisation to around 12..... The mesh generation might take a little longer, but the quality of the resulting meshes should become a little better. A great evening ahead! Philippose |
|
January 3, 2013, 14:32 |
|
#6 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
@Sandeep:
I'll try to use reconCentral. I don't think I'm going to find particular problems compiling the source. Actually I'm more worried about your next suggestion...I just want to be sure: is it possible with the current release of dynamictopofvmesh class to manage crushing cells (i.e. the closing valve example) ? If not, it seems to me that the piston engine video shows this functionality... am I so wrong ? @philippose: Many thanks ! I'm going to play a little with those parameters and see what happens...
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
January 3, 2013, 14:36 |
|
#7 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
You're right. Valve closure is not supported at the moment.
|
|
January 3, 2013, 15:18 |
|
#8 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
Well, that's....interesting. I'm not enought prepare to fully understand why it can't work but I'm still however interested in testing my cases.
Even because your class is the most automatic system you can have in OF that can manage dynamic meshes... is it ? I read a lot regarding GGI and AMI (but never try none of them) but, as you said, they seem too...delicate for my application. However easy question: is there any plan to support crushing cells in the near future ?
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
January 3, 2013, 15:25 |
|
#9 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Valve closure: Can't guarantee it. Mainly because I haven't found a need to do it till now. I could look into it if there's significant interest, but that largely depends on whether I have the time on my hands.
|
|
January 3, 2013, 15:58 |
|
#10 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
Ok. Thanks anyway for your work.
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
January 4, 2013, 01:18 |
|
#11 |
Senior Member
Daniele Vicario
Join Date: Mar 2009
Location: Novara, Italy
Posts: 142
Rep Power: 17 |
Just a small note:
In fvSolution, using relTol=0 brings the inlet flow rate to be equal to the outlet one since the very first step. This however increase each iteration time. Still don't know which value is better (from the speed point of view). Probably it depends on the case.
__________________
Daniele Vicario blueCFD2.1 - Windows 7 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Technical] Why are hex meshes better than tet? | bigphil | OpenFOAM Meshing & Mesh Conversion | 10 | July 18, 2016 12:20 |
Getting prism to inflate into mixed tet-hex meshes | Joe | CFX | 16 | October 10, 2011 07:06 |
[blockMesh] Blockmesh error - 2D scramjet | ishaninair | OpenFOAM Meshing & Mesh Conversion | 7 | March 18, 2011 00:14 |
[ICEM] how can i create a consistent transitions between tet and hex? specifically my model? | snailstb | ANSYS Meshing & Geometry | 3 | March 15, 2010 20:26 |
Hex versus Tet | Jade M | CFX | 1 | March 11, 2010 23:41 |