[boffin5]

My current project is to do CFD on a semi-truck, with an eye towards drag reduction. The first step is to get a simulation working with just the tractor part, adding the trailer later.

So I created a model of the tractor in Solidworks, and meshed it with Salome. Attached is an image showing the mesh of the stl file.

Now the problem: when I run snappyHexMesh on it, it fails with this message: "mpirun noticed that process rank 7 with PID 12576 on node localhost exited on signal 9 (Killed)."

My understanding of this message is that it indicates there is not enough system memory to do the job. However, I increased it from 8 to 20Gb, and it still fails.

Here is the confusing part. I have downloaded the drivaer standard check simulation, and when I run the run_all_shm.sh script, it runs okay. And this was with 8Gb of memory. And the drivear body2 stl file has a size of 67Mb, whereas my tractor stl file has a size of 21Mb.

So I ran surfaceCheck on both stl files. Here is the result for drivaer:

Surface is not closed since not all edges connected to two faces:
    connected to one face : 0
    connected to >2 faces : 1158
Conflicting face labels:7766
Dumping conflicting face labels to "problemFaces"
Paste this into the input for surfaceSubset

Number of unconnected parts : 3
Splitting surface into parts ...

Writing zoning to "zone_body2.vtk"...

writing part 0 size 60 to "body2_0.obj"
writing part 1 size 2 to "body2_1.obj"
writing part 2 size 367919 to "body2_2.obj"

Number of zones (connected area with consistent normal) : 1145
More than one normal orientation.

Then, I ran surfaceCheck on my tractor stl file:

Surface is not closed since not all edges connected to two faces:
    connected to one face : 984
    connected to >2 faces : 0
Conflicting face labels:984
Dumping conflicting face labels to "problemFaces"
Paste this into the input for surfaceSubset

Number of unconnected parts : 3
Splitting surface into parts ...

Writing zoning to "zone_tractor.vtk"...

writing part 0 size 117520 to "tractor_0.obj"
writing part 1 size 56 to "tractor_1.obj"
writing part 2 size 56 to "tractor_2.obj"

Number of zones (connected area with consistent normal) : 3
More than one normal orientation.

So there is seemingly no difference between the quality of the two stl files, and the drivaer file is bigger, but my case still fails because of lack of resources. What is going on here?

I hope that someone can help me clear this up, so I can get my case running.
Thanks in advance!

[Yann]

Hello Alan,

The memory usage is not really related to your STL size, but to your mesh size. If you have way more cells in your truck mesh, you could indeed hit the memory limit while a smaller mesh on DrivAer would not have any memory issues.

You can check the blockMesh size and refinement parameters in SHMDict to see if you have equivalent mesh sizes.
Another (maybe better) way is to check your SHM log right before the crash.

For instance:

Shell refinement iteration 4
----------------------------

Marked for refinement due to distance to explicit features : 0 cells.
Marked for refinement due to refinement shells             : 125340 cells.
Determined cells to refine in = 1.17 s
Selected for internal refinement : 126164 cells (out of 3823032)
Edge intersection testing:
    Number of edges             : 14252756
    Number of edges to retest   : 3754270
    Number of intersected edges : 43650
Refined mesh in = 12.48 s
After refinement shell refinement iteration 4 : cells:4706180  faces:14252756  points:4840825
Cells per refinement level:
    0	42996
    1	2960
    2	7072
    3	23024
    4	730624
    5	3899504
Skipping balancing since max unbalance 0.0884293 is less than allowable 0.1

This tells us we have 3823032 cells at the beginning of the refinement iteration, and 126164 cells selected to be refined.
After refinement we get 4706180 cells, and then you get the break down of the number of cells for each refinement level.

Try looking for this kind of information before SHM crash, and see if this is higher than the DrivAer mesh. I posted the shell refinement as an example but of course it might happens at a different moment in the SHM process. (Like during the add layers part if you create a lot of layers)

Note: the STL size usually don't make a difference, UNLESS you have very big STL files. But 67 and 21Mb files should not make any significant difference on your memory usage compared to the meshing process itself.

Regards,
Yann

[boffin5]

Thank You for your well-explained and comprehensive reply! After reading it, I doubled the cell size in my domain to reduce the count, and it solved the problem.


By the way, on another subject, is there any source that describes the useage of blockMeshDict.m4? In order to create a parametric blockMeshDict, I have been playing with it, with mixed results; it has been very finicky and I haven't made much headway.


Alan

[Yann]

Hello Alan,

I rarely used m4 so I don't really have any recommendation better than googling it.
Maybe someone else does though.

Regards,
Yann