[kandelabr]

Hello!

Once I described meshing process to a layman as a process where the domain is split into hexes. I also complained how insanely complicated and difficult that is but when I was asked to explain why, I had no idea.

I still don't know why but I'm thinking of writing a rather obvious and simple algorithm to chop a domain into a mesh. Before I throw myself into programming and waste months with it, I'd like to share it with you for comments and warnings.

This is how it goes:

1. Similar to snappyHexMesh, a background mesh would be a starting point.
2. Refinement and all the same as snappy.
3. Unlike snappy, instead of snapping cells to surface, I'd just cut them with it:
   1. Since cells wouldn't be deformed, non-orthogonality and skewness and stuff would be that problematic.
   2. Small details in geometry (smaller than cell size) would automatically get eliminated (one option)
   3. Cells almost completely cut away could be deleted and then snapping could be done much safer and easier
4. Adding layers: similar to snappy but in reverse:
   1. First, offset the surface by boundary layer thickness.
   2. Create internal mesh on the offset surface.
   3. Extrude faces to meet with the original geometry.

To me this algorithm seems a bit too obvious and that's why my all my alarms are going off.
Is there something I'm missing or should I give this a go? Does anything like that exist already?

Thanks for all your feedback.

[kandelabr]

Here's a simple hand-made example using CAD - cubes, cut with with a revolved surface.

Imagine straight edges and collapsed small/thin cells.

[flotus1]

Many algorithms may sound pretty straightforward and simple to implement. As long as you don't actually have to do it, but just write down bullet points
From time to time, I am still pushing updates to what is essentially a multi-level Cartesian grid generator. It has been years since I wrote the first line of code. Part of that is certainly feature creep, but a lot of it is just the reality of having to deal with complex, real-world geometries.

Let's just take one of your bullet points: "Small details in geometry (smaller than cell size) would automatically get eliminated (one option)"
Sounds easy enough. But now define what counts as a small detail, and how you can reliably and safely identify it through an algorithm.

Or this one: "First, offset the surface by boundary layer thickness."
First issue that comes to mind, and there might be many more: what happens when the offset surface is no longer inside the computational domain, because there was another wall too close.

Not trying to discourage you, but you should be aware of what you are getting yourself into.

[kandelabr]

Yes, these thoughts are exactly what I would like to hear - that's why I'm asking here.

The first point is pretty straightforward: when cutting a cell, only one triangle (I'm limiting myself to STL for now) can cut through a single edge (in case of many, choose a point that creates a shorter edge). So cut the edges and divide the cell, regardless of what's between them. Hehe, I can already see if()'s stacking

The second is not as simple. For a start I could just rely on user to operate within sane parameters and return garbage otherwise. It's the same with other meshers I know.

However, I am aware it's not going be simple and I also know these two thoughts are not the only problems I would encounter. But maybe, just maybe it'll be easier to fix problems created by a simple algorithm than, for instance, foamyHexMesh. That thing is so complicated that no one uses it. Also, it doesn't work.

Thank you for your input!

[sbaffini]

There is some material out there related to actual hexa grid generators that you might find useful.

One is the Ph.D. thesis of Kostantin Kovalev at Vrije Brussel under Hirsch and Lacor, that certainly has links with Hexpress by Numeca, the title being "Unstructured Hexahedral Non-conformal Mesh Generation".

You can also give a look at the series of paper by Prof. J. Wang on the 2^N tree cartesian grid generator, which became part of Fastran (at the time developed by CFD Research).

The international meshing roundtable is also a relevant source of information.

Finally, I recently discovered this project https://www.dgp.toronto.edu/projects/mandoline/ which promises what you seem to look for. But, honestly, I have doubts it can be done in a CFD context without control on the STL input.

Ideally, you can devise an approach that will always mesh any STL without difficulty (i.e., a trivial algorithm), but then you will have one or more of the following:

- severe quality degradation in the representation of the underlying geometry

- severe mesh quality degradation

- lack of features nowadays considered fundamental for usability, like the mentioned gap meshing, or the conformal meshing across STL surfaces for multiple zones

- lack of robustness

However, I would not consider SH as a reference in the field as, indeed, the number of times it can fail without proper care is certainly revealing of some issue

[kandelabr]

Thank you for your advice, I'll have a closer look into your links, it really does look similar to my ideas. That either confirms we're both right or we're all wrong =D

I also agree about your thoughts about geometry representation vs. quality degradation. In my opinion, it's far more important to have a high-quality mesh that omits minor details than detailed one that doesn't work. However, that's just my opinion based on my current experience.

Additional features you're talking about are yet to be thought about. A bit too early for my current plans...

Thank you for your comments!

[aerosayan]

Originally Posted by kandelabr

1. Unlike snappy, instead of snapping cells to surface, I'd just cut them with it:

To me this algorithm seems a bit too obvious and that's why my all my alarms are going off.

What's gonna be the surface normal of the cells when you use it in a CFD simulation, and how are you going to calculate the fluxes through this cells?


That would be the limiting factor.


I saw some papers use cells faces that were curved and conformed to the boundary shape. Your algorithm would produce a similar result. But those curved cell faces would need to be represented using some form of polynomial/nubs/bezier curves.


Your solver code also becomes more complicated while using this kind of grid.

[sbaffini]

Originally Posted by aerosayan

What's gonna be the surface normal of the cells when you use it in a CFD simulation, and how are you going to calculate the fluxes through this cells?


That would be the limiting factor.


I saw some papers use cells faces that were curved and conformed to the boundary shape. Your algorithm would produce a similar result. But those curved cell faces would need to be represented using some form of polynomial/nubs/bezier curves.


Your solver code also becomes more complicated while using this kind of grid.

I think he was considering just STL surfaces as input. Hence he would just end up with polyhedral cells with planar faces, nothing fancy to manage on the solver side, if he is actually able to produce them

[kandelabr]

Originally Posted by sbaffini

I think he was considering just STL surfaces as input. Hence he would just end up with polyhedral cells with planar faces, nothing fancy to manage on the solver side, if he is actually able to produce them

Yes, that's right.
There are two possible variants:

• conforming to every triangle of STL and making polyhedral cells or
• cutting only cube edges and making (more or less) planar faces from new points. Triangles inside the cell itself could easily be ignored.

I would say the first method would be much more complicated and could cause trouble with bad input surfaces, concave cells and so on. Also I don't really see the point in having that complex cells on boundary - details must be captured with many cells, not with a single complicated poly.

[sbaffini]

Originally Posted by kandelabr

Yes, that's right.
There are two possible variants:

• conforming to every triangle of STL and making polyhedral cells or
• cutting only cube edges and making (more or less) planar faces from new points. Triangles inside the cell itself could easily be ignored.

I would say the first method would be much more complicated and could cause trouble with bad input surfaces, concave cells and so on. Also I don't really see the point in having that complex cells on boundary - details must be captured with many cells, not with a single complicated poly.

Yes, the second one would be a sort of marching cubes. Still, a cube cut by a plane (i.e., a single triangle) is still a polyhedron in general and might also have polygonal faces.

[JBeilke]

The idea is not new. The same was done by cd-adapco and called "samm" and later "pro-am". The first version was published around 1997. Some of the possible cell types can be seen in the picture.

[kandelabr]

Originally Posted by JBeilke

The idea is not new. The same was done by cd-adapco and called "samm" and later "pro-am". The first version was published around 1997. Some of the possible cell types can be seen in the picture.

Very interesting stuff!
https://www.researchgate.net/publica...eration_in_CFD

I knew I wasn't the first to think of that

[aerosayan]

Originally Posted by sbaffini

I think he was considering just STL surfaces as input. Hence he would just end up with polyhedral cells with planar faces, nothing fancy to manage on the solver side, if he is actually able to produce them

Interesting. STL surfaces sometimes have very skewed triangulation to preserve memory space. Generally that's how it works in 3D industry, but in CFD, the STL surfaces may be of higher quality triangulation.

[sbaffini]

Originally Posted by aerosayan

Interesting. STL surfaces sometimes have very skewed triangulation to preserve memory space. Generally that's how it works in 3D industry, but in CFD, the STL surfaces may be of higher quality triangulation.

Well, no, I didn't mean that the result would be great or satisfy any quality criteria.

Just that, as he explicitly mentioned the STL input, that he would only have to deal with planar faces, by definition of STL.