[Temiz_CFD]

Open-source CFD has reached a level where solvers like OpenFOAM can match commercial codes in accuracy and physical modeling.
What still holds us back is robust, fast, and reliable meshing.

The main open-source option today, snappyHexMesh, works but remains limited in several key aspects:

Current Weak Points

1. Performance

Meshing is significantly slower than commercial tools, especially for large or complex geometries.

The refinement and snapping stages consume disproportionate CPU time.

2. Boundary Layer Generation

Layer addition is unreliable—layers frequently collapse near sharp corners, tight gaps, or concave regions.

Achieving y+ ≈ 1 for wall-resolved turbulence models is difficult.

3. Parameter Overload

The number of parameters in snappyHexMeshDict is excessive.

Small changes in settings can drastically alter outcomes, forcing long trial-and-error cycles.

There is no clear connection between input parameters and resulting mesh quality metrics.


Call for Collaboration

If you are interested in:

Improving meshing speed and scalability,

Making layer generation more robust,

Simplifying parameter handling and automation,

then you are invited to join a community effort to improve snappyHexMesh (or develop a next-generation open-source mesher).

Input from all users is welcome—please share any experience, frustration, or feature you believe needs to be fixed or improved. Every insight helps identify priorities and shape development directions.

Let’s bring open-source meshing closer to the reliability of commercial tools—transparent, efficient, and community-driven.

[klausb]

I have been looking into open source meshing, too.


I am not sure, snappyHexMesh is a good starting point and would like to suggest to evaluate a possible rewrite of "Engrid" which suffers from an outdated code base but has all the capabilities you/we are looking for especially when it comes to boundary layer meshing.


There is no quick fix via debugging!

[dlahaye]

Dear Klaus,

Many thanks for sharing your advice on this matter. Much appreciated.

Could you pls. elaborate on your suggestion? What should be done to bring Engrid to a modern implementation? Where should one start? What do you expect the gains to be?

Thanks again, Domenico.

[otaolafr]

hello,
I would recommend instead of trying to improve snappyHexMesh, to try instead to bring other meshers to the toolkit. such as for example:
https://github.com/fprotais/marchinghex
this is one of the most interesting developments in opensource (but there are other octree meshers that could be interesting), for the moment it is missing some escential features such as refinement levels, nevertheless I think in my humble opinion, but snappy is just too complex, too many variables not reliable enough. a lot of us have tried to 'give a meaning' in regards to the impact of the parameters without too much luck.
or revive cfmesh.... which gives comparable quality with only one parameter, would be better to invest time on it.

[klausb]

Originally Posted by dlahaye

Dear Klaus,

Many thanks for sharing your advice on this matter. Much appreciated.

Could you pls. elaborate on your suggestion? What should be done to bring Engrid to a modern implementation? Where should one start? What do you expect the gains to be?

Thanks again, Domenico.

To my knowledge Engrid was and is the only open source meshing software that provides very good boundary layer meshing functionality. It's also very easy to use. Unfortunately, it's not possible to install it on a recent Linux distribution as the dependencies and codebase are outdated. Upgrading the dependencies and codebase results in an unstable, constantly crashing installation. My understanding from related discussions I had is, that the underlying codebase has diverged a lot in areas like memory management which causes these issues. I've tried both Engrid 1.4 and Engrid 2.0 and so have others.

With "a modern implementation" I mean practically a re-implementation using a current software stack which may or may not be the same Qt + VTK... but that's a question for a software architect and should consider the programming skill level that can be expected from the people interested in further developing Engrid. I could be wrong as I lack the deep rooted application development / software know-how required for such a project. Other aspects to consider is the development workload and the team required to maintain an open source software project in the long term.