Snappyhex mesh not running properly

Hi everyone, I’ve been leaning on learning Butterfly and CFD analysis in general using Philip Galvan’s tutorial on Youtube (for a fact, for those who wish to learn Butterfly, I highly recommend: Butterfly CFD | Step by step Installation | Fluid dynamics Inside Rhino Grasshopper3D | Part 00 - YouTube).
Philip created a workflow in which he was able to extract the wind velocitie by running a Python script by the end of the solution, which removed the residual values. (also, is it a reliable workflow? just a doubt of mine)

Hence, I’m running some analysis on 3 different timesteps of an urban canyon in my city. I modelled the canyons morphology for the years of 1940, 1980 and 2020, and I was able to run the analysis with no errors on the 1940 and 1980’s morphology. However, on 2020’s morphology (which is relatively taller and denser), the Snappyhex Mesh does not complete the meshing proccess. The meshing error occurs according to the angle I’m rotating the geometry to obtain the wind patterns according to the wind direction extracted from the epw file (respectively running on 295,317 and 331 degrees)
I’ve tried to increase the wind tunnel’s dimensions, lower the cell size, increased the max_global_cells and the glob_refinement_level and still, the meshing process does not finish properly.
Any hints on how to make it work properly?

Here are the files I’m using, I uploaded it on Drive because it is too large to upload it here on the forum.

And also, I’d like to thank you all for all the help throughout my master’s degree, looking forward to contributing to Ladybug’s team with my research.

Warm regards everyone! Hope you all have a nice day and week

Just to illustrate, here are some outdoor airflow results I ran for 1940’s morphology, just to show the results.
Here’s the wind velocity results (it ran for 500 iterations only, since it is a preliminary result) and the wind direction was set to 319 degrees

Furthermore, I was able to set a UTCI map that accounted for the wind patterns on the canyon’s space.

Here’s for 1980’s morphology, the wind direction is the same as the previous analysed morphology, and the simulation ran for 500 iterations as well.

And here’s the UTCI map.

Only the 2020’s morphology is the one that was not able to run the snappyhex mesh properlly. But, I’ll keep experimenting different workflows to see if it’ll work, on the other hand, tips and hints are always welcome as usual hehehe.
Nonetheless, I just wanted to share some results of my research with you all, I’m really excited of using Ladybug and contributing to the team.

@minggangyin @OlivierDambron @TheodorosGalanos got any tips on how to make the simulation workflow better? :blush:
Constructive criticism is always welcome

It always starts from the mesh :slight_smile:

Sounds simplistic, but geometry processing/cleaning and meshing is about 99% of the study (especially when using OpenFOAM).

I would recommend to clean up geometries, one by one if necessary. This is absolutely terrible work but it does help solve a lot of issues. Simplifying also helps, merging a lot of small, disparate geometries into one building for example, and cleaning up surface meshes (leading to less surfaces and better meshing).

And then experiment with meshing quality. Better meshes will take longer to run (per iteration) but can converge faster (and will be more accurate).

1 Like

Thank you so much for the tips.
You mean deleting these small gaps between buildings make the simulation more accurate? I was worried about that, creating a more refined mesh really increases the solution time, but knowing it’ll converge faster makes it easier.
The problem I’m having meshing the model is happening on different angles I’m rotating the geometry, for example, now I’m having trouble meshing the model at 331 degrees, but still, I’ll keep trying different mesh qualities and etc.
Here’s a screenshot of the end of the snappyhexmesh log, maybe the software is not able to create a good mesh for simulating right?

Yes if the gap is so small you don’t need the wind to move though it, then align the buildings to remove it. Same goes for setbacks in facades etc.

Rule of thumb meshing rules (I’m open for alternatives!)

My general rule of thumb is that a setback needs at least 2-3 cells in order to “work” meshwise and 5-10 in order to be reliable simulationwise.

For corridors etc at least 10-20 cells for it to be sort of reliable. At 3-5 cells it can “run” but it will slow the wind and your results look too good. It’s like cutting a corner off a bag of peanuts. If the hole is size of 2 peanuts, the flow will be slow. If you use same hole for rice it goes fast. So either refine it to finer cells (rice) or increase the hole.

What does this mean? If your outer cell size is 20m and your refinement level is 5 then the cells will be 20/(2^5) = 0.6m. this should be ok for setbacks of 1.5m size to “work”. If you need the precision to show the effect of the 1.5m setback, you would need a cell size of 0.3m ish.

Also remember to model edges explicitly. So two rectangles overlapping into a L shaped building should be boolean unioned. So the inner corner of the L has a visible edge.

So… This reveals the issue usually: the context mesh needs less of precision so people turn up the cell size here. However this is imported garbage so you actually need smaller cell size or cleaner geometry. Paradox.

Rule of thumb is around 0.5m cell size close to your buildings of interest. And trees at least 3-5 cells wide.

And always check your mesh manually in para view before running. Do vertical and horizontal slices so you can inspect the cells.
Also run a checkMesh command. If it fails the checkMesh there’s a big risk of the simulation “exploding” where pressure and velocities keep accelerating up to astronomical values until the simulation stops.

All the best,
Mathias Sønderskov Schaltz

1 Like