|
[Sponsors] |
simpleFoam crashes after a few iterations - mesh issue? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 27, 2020, 06:24 |
simpleFoam crashes after a few iterations - mesh issue?
|
#1 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hey all,
I am currently having some issues running a simulation of a generic vehicle model. The simulation starts fine, but after a handful of iterations (somewhere between 10 and 50, depending on relaxation factors and other parameters) the residuals start to grow again and the force coefficients go to infinity. My main suspect at the moment is the mesh. (I replaced the mesh file with a simple mesh around an airfoil and everything worked fine. So I think there is no issue with the control files.) As this is a really complex simulation with coanda actuation at multiple locations of the vehicle, I used Pointwise V18R3.1 to create the grid. It consists of 24 fully structured blocks, which are resolving the base, and 2 unstructured blocks, for the remainder of the mesh. They add up to about 33 Mio cells. The highest skewness in the mesh is 0.93, the highest non-orthogonality around 86. These are not the best values, but it is very hard to improve and I was able to run a simple airfoil case with a much worse mesh stable and without any errors. Now as for whatever reason the mesh export from Pointwise to OpenFOAM does not work for me, I exported the mesh as well as all the boundary conditions as a Fluent Case (.cas) and used "fluent3DMeshToFoam" to create the polyMesh folder. That works without any error messages. After modifying the boundary file the simulation starts without any problems but as I said, it eventually crashes. And I have no idea why. These are some of my thoughts: -Is there maybe a problem between the interfaces of the structured and unstructured blocks. Do i need to define those in Pointwise? -Are there problems using "fluent3DMeshToFoam" with a mesh consisting of multiple structured and unstructured blocks? One thing I noticed was for example, that the highest Aspect Ratio in Pointwise was 600, whereas checkMesh gave me a value of 4000. What is happening here? Other suspects other than the mesh I have are: -the mesh decompostion method (hierarchical, 44 cores) -the unsteady nature of a flow around the vehicle, which kills the steady solver Has anyone experienced similar problems before? Thanks in advance! Best, Niklas |
|
July 27, 2020, 07:10 |
|
#2 | ||
Senior Member
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13 |
Hi Niklas,
Does checkMesh give any other warnings/errors besides the one from non-orthogonality? Non-orthogonality of 86 is very high. Where are those faces located? Quote:
Quote:
Have you tried running renumberMesh utility (see this thread)? What is your initial condition? Have you tried running potentialFoam for better initial condition? Best, Mikko |
|||
July 27, 2020, 07:47 |
|
#3 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hi Mikko,
thanks for the quick answer! Here is my checkMesh output: Code:
Create time Create polyMesh for time = 0 Time = 0 Mesh stats points: 18760162 faces: 84104255 internal faces: 83292147 cells: 32918638 faces per cell: 5.08515577102552 boundary patches: 9 point zones: 0 face zones: 1 cell zones: 1 Overall number of cells of each type: hexahedra: 7173884 prisms: 20861103 wedges: 0 pyramids: 512979 tet wedges: 0 tetrahedra: 4370672 polyhedra: 0 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 fahrbahn 90495 45772 ok (non-closed singly connected) gts 498811 297337 ok (non-closed singly connected) gts_apc1 2574 2700 ok (non-closed singly connected) gts_apc2 5174 5400 ok (non-closed singly connected) gts_basecoanda 26373 27000 ok (non-closed singly connected) inlet 390 221 ok (non-closed singly connected) outlet 384 218 ok (non-closed singly connected) symmetry 158530 138078 ok (non-closed singly connected) tunnelwalls 29377 23546 ok (non-closed singly connected) Checking geometry... Overall domain bounding box (-2.845500000000269 -0.6485028565962671 -0.2335000000000143) (5.121900002274432 1.707577135245941e-11 1.056500000000007) Mesh has 3 geometric (non-empty/wedge) directions (1 1 1) Mesh has 3 solution (non-empty) directions (1 1 1) Boundary openness (5.105096112799656e-19 1.107282910693495e-16 -5.977573554821716e-16) OK. ***High aspect ratio cells found, Max aspect ratio: 4122.316528636494, number of cells 33168 <<Writing 33168 cells with high aspect ratio to set highAspectRatioCells Minimum face area = 5.399805030465543e-14. Maximum face area = 0.009414215273321262. Face area magnitudes OK. Min volume = 1.734020921955219e-20. Max volume = 0.0002615864076232943. Total volume = 6.626320330408396. Cell volumes OK. Mesh non-orthogonality Max: 86.12726556753162 average: 11.31993095783164 *Number of severely non-orthogonal (> 70 degrees) faces: 64870. Non-orthogonality check OK. <<Writing 64870 non-orthogonal faces to set nonOrthoFaces Face pyramids OK. Max skewness = 2.519051558848287 OK. Coupled point location match (average 0) OK. Failed 1 mesh checks. End The high aspect ratio is due to the tight wall spacing I need to resolve the coanda jets. But as I said, the value stated here (4122) does not match the value Pointwise gives me. The skew cells are mainly located around the wheels of the model (concave corners), as well as around the A-Pillar, where I set up a seperate block to resolve the coanda actuation. I tried running potentialFoam to initialize the solution, which definetly helped, but eventually the simulation still crashes. I attached a plot of the drag coefficient over the number of iterations. At the beginning, everything looks fine, but after around 50 iterations, the simulation starts to collaps. My write precision is at 16. What exactly does this setting? Yeah, I actually stumbled across this post earlier, good thing you reminded me. I tried it again and it actually solves the original problem with the mesh export. Now I don't need to export it as a Fluent case anymore and can leave out the step with Fluent3DMeshToFoam. Thanks! I'll try if that changes anything with the solution. Best, Niklas |
|
July 27, 2020, 07:57 |
|
#4 |
Senior Member
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13 |
Hi Niklas,
The mesh seems fine besides the non-orthogonality might be an issue depending on where the faces are located. If I interpret rightly your checkMesh log, you have a surface mesh which is dominated by triangles and you extrude the surface mesh to a prism dominated boundary layer mesh. What about your fvSchemes? With a prism/tetra mesh you have to adjust the schemes from the "default ones". Best, Mikko |
|
July 27, 2020, 08:12 |
|
#5 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hey Mikko,
exactly, I created an unstructured surface mesh and used Pointwises T-Rex Algorithm to extrude prisms in the boundary layer and build tets in the farfield. Here's my fvSchemes. What schemes exactly do I have to adjust there, which are related to the cell types? Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.1.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; location "system"; object fvSchemes; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // ddtSchemes { default steadyState; } gradSchemes { default Gauss linear; grad(U) cellLimited Gauss linear 1; grad(nuTilda) cellLimited Gauss linear 1; } divSchemes { default none; div(phi,U) bounded Gauss linearUpwindV grad(U); div(phi,k) bounded Gauss upwind; div(phi,omega) bounded Gauss upwind; div((nuEff*dev2(T(grad(U))))) Gauss linear; div(phi,nuTilda) bounded Gauss upwind; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } wallDist { method meshWave; } // ************************************************************************* // What I also just noticed there: The header states "version 2.0", but I am using OpenFOAM 7. Can that cause problems? Best, Niklas |
|
July 27, 2020, 12:15 |
|
#6 |
Member
Join Date: Oct 2011
Posts: 51
Rep Power: 14 |
Why don't you use scotch decomposition?
You have a lot of tets. And about the FOAM file version, the foam header is commented out, so that cannot be an issue. edit: Sorry, of course the header is commented out, but foam file version 2.0 is correct for openfoam7 as i can see. Last edited by fanta; July 28, 2020 at 06:42. |
|
July 28, 2020, 03:45 |
|
#7 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hey fanta,
I tried using scotch decomposition in the first place, but for whatever reason, if I run decomposePar, OpenFOAM throws all cells in Processor 0 and leaves the other 43 processors empty. Do I have to specify something in decomposeParDict? |
|
July 28, 2020, 06:35 |
|
#8 |
Member
Join Date: Oct 2011
Posts: 51
Rep Power: 14 |
You could start with a very simple decomposeParDict:
Code:
numberOfSubdomains 44; method scotch; |
|
July 28, 2020, 10:10 |
|
#9 |
Senior Member
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13 |
Hi Niklas,
I don't have much experience with tetrahedral meshes but there are several threads on this forum where you can get more information. This thread might be of your interest. Another thing that came to my mind are the non-orthogonal correctors. You could try to use many correctors in the beginning of your simulation. Best, Mikko |
|
July 29, 2020, 08:41 |
|
#10 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hey fanta,
also with this simple decomposeParDict, I am still running into the same problem. All of the cells are assigned to the first processor and all other processors are left empty. Any idea why that happens? |
|
July 29, 2020, 08:44 |
|
#11 |
New Member
Join Date: May 2020
Posts: 7
Rep Power: 6 |
Hey Mikka,
thanks for the help. I'll be sure to check out the other post and try out some stuff. The number of NonOrthogonal Correctors indeed looks like it is helping a bit with the convergence. Best, Niklas |
|
July 29, 2020, 11:19 |
|
#12 |
Senior Member
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20 |
Hi Niklas,
your max. non-orthogonality is quite high, this is most likely the reason for convergence problems. It should be more beneficial to set Code:
default Gauss linear limited 0.5; Code:
default limited 0.5; Besides, with an aspect ratio of more than 4000 it is maybe questionable if you will get correct results... Best, Jan |
|
Tags |
fluent3dmeshtofoam, mesh, openfoam, pointwise, simplefoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Problem with chtMultiregionFoam radiation boundary condition | baran_foam | OpenFOAM Running, Solving & CFD | 10 | December 17, 2019 17:36 |
laplacianFoam with source term | Herwig | OpenFOAM Running, Solving & CFD | 17 | November 19, 2019 13:47 |
Micro Scale Pore, icoFoam | gooya_kabir | OpenFOAM Running, Solving & CFD | 2 | November 2, 2013 13:58 |
calculation stops after few time steps | sivakumar | OpenFOAM Running, Solving & CFD | 7 | March 17, 2013 06:37 |
Convergence moving mesh | lr103476 | OpenFOAM Running, Solving & CFD | 30 | November 19, 2007 14:09 |