CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

simpleFoam crashes after a few iterations - mesh issue?

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By Flowkersma
  • 1 Post By Flowkersma

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 27, 2020, 06:24
Default simpleFoam crashes after a few iterations - mesh issue?
  #1
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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
NiklasH108 is offline   Reply With Quote

Old   July 27, 2020, 07:10
Default
  #2
Senior Member
 
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13
Flowkersma is on a distinguished road
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:
-Is there maybe a problem between the interfaces of the structured and unstructured blocks. Do i need to define those in Pointwise?
See in checkMesh output if you have several mesh regions.

Quote:
-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?
Is your writePrecision high enough?


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
NiklasH108 likes this.
Flowkersma is offline   Reply With Quote

Old   July 27, 2020, 07:47
Default
  #3
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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
Attached Images
File Type: png forceCoeffs.png (19.9 KB, 10 views)
NiklasH108 is offline   Reply With Quote

Old   July 27, 2020, 07:57
Default
  #4
Senior Member
 
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13
Flowkersma is on a distinguished road
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
NiklasH108 likes this.
Flowkersma is offline   Reply With Quote

Old   July 27, 2020, 08:12
Default
  #5
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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
NiklasH108 is offline   Reply With Quote

Old   July 27, 2020, 12:15
Default
  #6
Member
 
Join Date: Oct 2011
Posts: 51
Rep Power: 14
fanta is on a distinguished road
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.
fanta is offline   Reply With Quote

Old   July 28, 2020, 03:45
Default
  #7
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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?
NiklasH108 is offline   Reply With Quote

Old   July 28, 2020, 06:35
Default
  #8
Member
 
Join Date: Oct 2011
Posts: 51
Rep Power: 14
fanta is on a distinguished road
You could start with a very simple decomposeParDict:


Code:
numberOfSubdomains 44;

method          scotch;
fanta is offline   Reply With Quote

Old   July 28, 2020, 10:10
Default
  #9
Senior Member
 
Mikko
Join Date: Jul 2014
Location: The Hague, The Netherlands
Posts: 243
Rep Power: 13
Flowkersma is on a distinguished road
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
Flowkersma is offline   Reply With Quote

Old   July 29, 2020, 08:41
Default
  #10
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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?
NiklasH108 is offline   Reply With Quote

Old   July 29, 2020, 08:44
Default
  #11
New Member
 
Join Date: May 2020
Posts: 7
Rep Power: 6
NiklasH108 is on a distinguished road
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
NiklasH108 is offline   Reply With Quote

Old   July 29, 2020, 11:19
Default
  #12
Senior Member
 
JNSN's Avatar
 
Jan
Join Date: Jul 2009
Location: Hamburg
Posts: 140
Rep Power: 20
JNSN is on a distinguished road
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;
for laplacianSchemes and
Code:
default limited 0.5;
for the snGradSchemes instead of increasing the non-ortho correctors, as you are running simpleFoam.
Besides, with an aspect ratio of more than 4000 it is maybe questionable if you will get correct results...


Best,
Jan
JNSN is offline   Reply With Quote

Reply

Tags
fluent3dmeshtofoam, mesh, openfoam, pointwise, simplefoam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


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


All times are GMT -4. The time now is 01:34.