|
[Sponsors] |
September 8, 2014, 10:22 |
influence of mesh structure
|
#1 |
New Member
Jens
Join Date: Apr 2014
Posts: 28
Rep Power: 12 |
Hello,
i'm using dbnsTurbFoam with LRR turbulence modeling to simulate the mixing process of core- and bypass stream in a jet engine. I created a structured mesh for a slice of the geometry and applied cyclic boundaries. Due to the complex geometry of the forced mixer between core and bypass, the mesh contains a V-shaped Structure. My foam solutions are obviously effected by this structure whereas a fluent calculation on the same mesh shows smooth vortexes (see pictures). I had a similar problem with rhoCentralFoam. I use the following schemes: Code:
ddtSchemes { default Euler; } gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,k) Gauss upwind; div(phi,epsilon) Gauss upwind; div(devRhoReff) Gauss linear; div((devRhoReff&U)) Gauss linear; div(phi,R) Gauss limitedLinear 1; div(R) Gauss linear; } laplacianSchemes { default none; laplacian(DkEff,k) Gauss linear limited 0.5; laplacian(DepsilonEff,epsilon) Gauss linear limited 0.5; laplacian(alphaEff,e) Gauss linear limited 0.5; laplacian(alphaEff,h) Gauss linear limited 0.5; laplacian(DREff,R) Gauss linear limited 0.5; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; } Thanks for your help. Jens |
|
September 16, 2014, 12:26 |
|
#2 |
New Member
Jens
Join Date: Apr 2014
Posts: 28
Rep Power: 12 |
No suggestions?
I mean I can change the mesh, but i wonder why it works with fluent. And even a mesh without the V-shape wouldn't be orthogonal so it would still influence the flowfield. Thanks for your help! |
|
September 21, 2014, 11:59 |
|
#3 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Greetings Jens,
OpenFOAM can be pretty picky about meshes. I've seen some interesting situations and documented them here: OpenFOAM: Interesting cases of bad meshes and bad initial conditions Furthermore the presentation "OFW09.0005 How grid quality affects solution accuracy" available at http://openfoam-extend.sourceforge.n.../download.html gives a pretty good description/analysis on this topic! Beyond this, from the images, I can state two tips right off the bat:
Bruno
__________________
|
|
September 22, 2014, 04:58 |
|
#4 |
New Member
Jens
Join Date: Apr 2014
Posts: 28
Rep Power: 12 |
Hi Bruno,
thanks for the links. I already knew the OFW09.0005 presentation and found it very interesting. It gives a good explanation why my mesh is not so good . BUT fluent seems not to care about it and the riemann-solver of Oliver Borm neither. I try to figure out what makes the difference. To answer your questions: 1. Code:
solvers { rho {} rhoU {} rhoE {} k { solver PBiCG; preconditioner DILU; tolerance 1e-08; relTol 0.01; } epsilon { solver PBiCG; preconditioner DILU; tolerance 1e-08; relTol 0.01; } R { solver PBiCG; preconditioner DILU; tolerance 1e-10; relTol 0.01; } } 3. Code:
Initializing the GGI interpolator between master/shadow patches: pr1/FaceGroup46 Time = 0.00633488 Mesh stats all points: 1218912 live points: 1218912 all faces: 3559903 live faces: 3559903 internal faces: 3463877 cells: 1170630 boundary patches: 14 point zones: 0 face zones: 13 cell zones: 1 Overall number of cells of each type: hexahedra: 1170630 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 Area [m^2] Surface topology nacelle 6732 6956 0.961432 ok (non-closed singly connected) mixer 2536 2715 0.0657216 ok (non-closed singly connected) lower_bypass_duct 4500 4641 0.184251 ok (non-closed singly connected) upper_core_duct 4410 4575 0.0317756 ok (non-closed singly connected) lower_core_duct 4356 4530 0.0442502 ok (non-closed singly connected) guide_vane 2132 2184 0.0323396 ok (non-closed singly connected) mixer-shadow 2536 2715 0.0657216 ok (non-closed singly connected) farfield_outlet 6624 6803 1.04829 ok (non-closed singly connected) farfield 2880 2997 3.07944 ok (non-closed singly connected) farfield_inlet 1008 1073 0.966654 ok (non-closed singly connected) pr1 26582 27026 6.42692 ok (non-closed singly connected) bypass_inlet 2646 2752 0.0447299 ok (non-closed singly connected) core_inlet 2502 2634 0.0187553 ok (non-closed singly connected) FaceGroup46 26582 27026 6.42692 ok (non-closed singly connected) Checking geometry... This is a 3-D mesh Overall domain bounding box (-1.87781 -0.480979 -4.75413e-09) (1.29674 0.480979 2.1615) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty) directions (1 1 1) Mesh (non-empty, non-wedge) dimensions 3 Boundary openness (-2.24215e-17 -1.00571e-15 -1.06939e-15) Threshold = 1e-06 OK. Max cell openness = 3.26762e-15 OK. Max aspect ratio = 392.632 OK. Minumum face area = 6.2554e-09. Maximum face area = 0.010648. Face area magnitudes OK. Min volume = 1.67449e-12. Max volume = 0.00029025. Total volume = 3.29267. Cell volumes OK. Mesh non-orthogonality Max: 80.2948 average: 18.1626 Threshold = 70 *Number of severely non-orthogonal faces: 3085. Non-orthogonality check OK. Writing 3085 non-orthogonal faces to set nonOrthoFaces Face pyramids OK. Max skewness = 3.63031 OK. Mesh OK. Thanks again for your help. I'm really stuck at the moment so I appreciate every suggestion. Jens |
|
September 26, 2014, 05:08 |
|
#5 |
New Member
Jens
Join Date: Apr 2014
Posts: 28
Rep Power: 12 |
Moinmoin,
I could improve my results by changing the approximate Riemann-solver from Rusanov to Roe method. I also changed the Limiter to Venkatakrishnan. Honestly I don't understand why this makes things better. I thought it should be some non-orthogonal or skew correction in the fvSchemes (where is div(dbnsFlux.rhoFlux) defined? i couldn't find it). To achieve better stability I used the following fvSchemes: Code:
gradSchemes { default Gauss linear corrected; } divSchemes { default none; div(phi,k) Gauss upwind cellLimited Gauss linear 1; div(phi,epsilon) Gauss upwind cellLimited Gauss linear 1; div(devRhoReff) Gauss linear; div((devRhoReff&U)) Gauss linear; div(phi,R) Gauss upwind cellLimited Gauss linear 1; div(R) Gauss upwind cellLimited Gauss linear 1;//Gauss linear; } laplacianSchemes { default none; laplacian(DkEff,k) Gauss upwind phi corrected; laplacian(DepsilonEff,epsilon) Gauss upwind phi corrected; laplacian(alphaEff,e) Gauss linear corrected; laplacian(alphaEff,h) Gauss linear corrected; laplacian(DREff,R) Gauss upwind phi corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; } Thanks, Jens P.S.: My calculation are still very time-consuming due to the fact that I have to use cyclicGgi as globalFaceZones instead of cyclics to get my rsm model run. (http://www.cfd-online.com/Forums/ope...onditions.html) |
|
April 6, 2015, 07:53 |
|
#6 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Jens,
I've had this on my to-do list and it took me a long time to get back to you on this. Fortunately I know some more details today than I knew a few months ago. Regarding the latest post, there are a few entries that you have that won't do anything at all, due to how each scheme is designed to work... although I'm assuming this is the same for both foam-extend 3.1 and OpenFOAM 2.x (I'm more familiar with OpenFOAM). The following is what the solver is probably using: Code:
gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,k) Gauss upwind; div(phi,epsilon) Gauss upwind; div(devRhoReff) Gauss linear; div((devRhoReff&U)) Gauss linear; div(phi,R) Gauss upwind; div(R) Gauss upwind; } laplacianSchemes { default none; laplacian(DkEff,k) Gauss upwind phi corrected; laplacian(DepsilonEff,epsilon) Gauss upwind phi corrected; laplacian(alphaEff,e) Gauss linear corrected; laplacian(alphaEff,h) Gauss linear corrected; laplacian(DREff,R) Gauss upwind phi corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } fluxRequired { default no; }
Best regards, Bruno |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[ICEM] Orthogonality/Skew issues in 3D unstructured mesh | eddyy19g | ANSYS Meshing & Geometry | 3 | February 13, 2014 09:36 |
[GAMBIT] Structure Mesh for Cyclon | green iran | ANSYS Meshing & Geometry | 4 | July 11, 2012 11:04 |
Influence of mesh refinement on the convergence | saisanthoshm88 | CFX | 6 | November 26, 2010 06:58 |
[snappyHexMesh] external flow with snappyHexMesh | chelvistero | OpenFOAM Meshing & Mesh Conversion | 11 | January 15, 2010 19:43 |
Icemcfd 11: Loss of mesh from surface mesh option? | Joe | CFX | 2 | March 26, 2007 18:10 |