Problems with mesh computing


Hello, I´m having problems with the mesh of my project.
This is the project link:

Yesterday I completed a succesfull simulation but wanted to make a more refined mesh with a new geometry. Then, I just duplicated the mesh I had created previously, updated the geometry and assigned the values I wanted for the second mesh.

I have tried to generate the mesh many times but after a few minutes running it always fails with this kind of message:

“mpirun noticed that process rank 7 with PID 207 on node 374440b5c6bf exited on signal 9 (Killed).”

I have already tried to change the number of cores used for the calculation, but it didn´t work.

I would really appreciate if someone could take a look at my project and help me to solve this issue, thanks everyone!


Hi @eduardocclc,

I started remeshing your model few hours ago and see if I get the same error. I will get back to you!

In the meantime, stay patient :wink:



Thanks for your help jousefm!

I just tried to create a new mesh from scratch. It ran for 4 hours and i got this error message in the end:

truncateDisplacement : Unextruded 0 faces due to non-consecutive vertices being extruded.
truncateDisplacement : Unextruded 0 faces due to stringed edges with inconsistent extrusion.
Setting up information for layer truncation …
new cannot satisfy memory request.
This does not necessarily mean you have run out of virtual memory.
It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library
[4a6df05ba274:00225] *** Process received signal ***
[4a6df05ba274:00225] Signal: Aborted (6)
[4a6df05ba274:00225] Signal code: (-6)
[4a6df05ba274:00225] [ 0]
[4a6df05ba274:00225] [ 1]
[4a6df05ba274:00225] [ 2]
[4a6df05ba274:00225] [ 3]
[4a6df05ba274:00225] [ 4]
[4a6df05ba274:00225] [ 5]
[4a6df05ba274:00225] [ 6]
[4a6df05ba274:00225] [ 7]
[4a6df05ba274:00225] [ 8]
[4a6df05ba274:00225] [ 9]
[4a6df05ba274:00225] [10]
[4a6df05ba274:00225] [11]
[4a6df05ba274:00225] [12] snappyHexMesh[0x43c2ab]
[4a6df05ba274:00225] [13]
[4a6df05ba274:00225] [14] snappyHexMesh[0x414e21]
[4a6df05ba274:00225] *** End of error message ***

mpirun noticed that process rank 12 with PID 212 on node 4a6df05ba274 exited on signal 9 (Killed).


Hi @eduardocclc,

your mesh is way too fine. I would recommend you try to lower the mesh refinements and tell me if that worked. Also try to work with 2 instead of 3 boxes around your wings.

If you still struggle to get it done just let me know. :wink:

Good luck!



A few updates on the project:

I manage to run 2 meshes and 2 simulations wich converged well.
Yesterday, I tried to upload 2 new geometries and generate more meshes with them, but I had many errors with the meshing process. Today I could run some meshes but they ended up having lots of problems, as you can see in the pictures

I tried to run some simulations with these glitched meshes but they failed as well.

All the Mesh and simulations parameters I´m using came from the FSAE webinar session 1 and from a spreadsheet @Milad_Mafi posted in one of the FSAE threads.

I also saw in another thread that there is a problem with the mesh algorithm since the last platform update, so I don´t know if this is the cause of the issues I´m experiencing.

If anyone could take a look at my project and the logs of the failed meshes and simulations, I would be really grateful.

Thanks guys


Hi @eduardocclc,

I will have a look at that. @afischer: Any comments on the platform updates and if those correlate with the meshing issue?




Here is the project link for an updated Mesh: Project

I made some adjustments (deleting mesh refinement for Background Mesh Box etc…). The Mesh looks fine now. However, I did not run a simulation with that mesh. Tell me if you still encounter any problems.




I just ran a simulation with your mesh and it worked fine!

I also generated another mesh based on yours with a different geometry and it was great too.

However I´m concerned about the changes you made and what I was doing wrong. I noticed you deleted one of the cartesian boxes, and deleted the refinements on the background mesh box.

I think I might be messing with the layers size. I´m using this spreadsheet for calculating the final layer thickness. If I´m not mistaken, the value it outputs is in meters, wich means I shouldn´t use the relative size option for the layers generation.

And last, I´m a bit confused about what is the desired Y+ value I should be seeking. I´ve read some articles about it and some say it should be 1, others say it shouldn´t be between 3 and 30 or that it should be between 30 and 100. I would like some clarifications on this subject, please.

By the way, thank you for your help, Simscale support is awesome!


Hi @eduardocclc,

first of all thank you for your kind words! :slight_smile: We try our best :wink:

Regarding the Mesh I first wanted to get rid of the “glitch” you were talking about. You could try adding this Background Mesh Box 1 - 1 Refinement again and see what it does. CFD is an iterative process anyway so expecting to have the right settings at the beginning is quite optimistic, well at least in my opinion…

Your question about the Y+ value is very valid and it has only been discussed once by our PowerUser @Maciek in this Post where he looks at the ISOsurfaces trying to make statements about the choice of Y+.

I am not an expert and would like to invite our PowerUsers @dylan, @1318980 and @Maciek to this discussion. But as far as I know in order to get an accurate simulation the first cell center must be inside the viscous layer we are looking at. Usually we consider Y+ to be smaller than 4.

BUT the size of your first cell must correspond to your turbulence model. For example k-omega SST requires a Y+ smaller than 1 whereas k-epsilon requires a Y+ of 30 - 60. I do not have values for LES though but we have to distinguish between fluctuations generated by shear at the wall & those generated by flow shear. I read on some pages that a Y+ of 1 is required. This would allow your LES model to capture the transition from the viscous layer to the developed layer with the appropriate turbulent energy transfer.

You can use the approach of @Maciek in order to get your Y+ (so during Post-Processing).

There are several tools out there that may help you esimating your Y+ , for instance:

I hope I could help you a bit with that. Looking forward to hear what our PowerUsers have to say to that and hopefully correct me if I made a mistake :slight_smile:




Hi guys, I don’t think I’m expert enough to give an in-depth explanation but I used a resource that has helped me get my head round it when I was reading up on it:

I found it helpful to be able to visually see the relation between U+, y+ and the regions of the boundary layer. It gets a bit technical toward the end but the explanations are a very good starting point.

Sorry I can’t be more helpful,


All omega-based models are continuous (can be integrated to wall without damping functions), so doesn’t matter what y+ there will be k, omega, nut (if use Spalding wall function) values on the wall patches. But, there is no general way of applying a turbulence model with the first cell in y+=5-30 due to large variations in different turbulence source terms. It is recommended that you use either y+=1 or y+>30:

  1. y+<5 is (generally) acceptable, and you can’t possibly have y+=1 everywhere. Stagnation points and regions with flow separations can go below unity. I always use y+<5 in design when I don’t wish to use y+>30, but 99% of the time I use y+>30. There are always regions where y+ is less than 30, but you should keep the area as small as possible.
  2. You don’t need to use y+<1 in non-transitional RANS.

StandardKE and realizableKE ( in their original forms) are high Reynolds number turbulence models. Use y+>30. Some codes allow high-Re models to integrate to wall, but there is no such wall treatment on SimScale.

RealiableKE is the most suitable turbulence model available on SimScale for your purpose. It yields relatively low nut in vortex cores, doesn’t have nut build-up in stagnation points, and is very good in strong adverse pressure gradient.


It is not easy to solve a low-Re grid generated by snappyHex. You can’t just solve the grid with y+<5 using 3 cells in the boundary layer. It is important that the entire boundary layer is covered by boundary-layer cells, and the growth rate is kept below 1.2. This means there will be at least 12~15 cells. You will find it hard to create that many cells using snappyHex.


Thanks for your answers, guys!

Dylan, this is the y+ contour of one of the simulations:

It´s below 1 on most of the surface of the wing, and between 10 and 60 on the ground.

For the wing there are 5 layers with a growth rate of 1.8. For the floor there are 3 layers with a growth rate of 1.3.

These are the convergence monitors of the simulation:

My conclusion is that the mesh near the ground is bad, but it seems possible to achieve good results with 5 layers only.

I´ll make a more refined mesh on the ground I see what happens.


Hi eduardocclc

I have got two points:

  1. You can use boundary-layer cells on the ground to reduce y+

  2. I am confused by ‘good results’. Do you mean good results as in converged results, or as in results that match (available) experimental data? It you simply aim for convergence, you don’t really need 5 layers.