[NiklasH108]

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

[Flowkersma]

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?

-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.

-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]

Hi Mikko,
thanks for the quick answer! Here is my checkMesh output:

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

[Flowkersma]

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]

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?

/*--------------------------------*- 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

[fanta]

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.

[NiklasH108]

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?

[fanta]

You could start with a very simple decomposeParDict:

numberOfSubdomains 44;

method          scotch;

[Flowkersma]

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

[NiklasH108]

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]

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

[JNSN]

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

default Gauss linear limited 0.5;

for laplacianSchemes and

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