[Astrodan]

Servus everyone,

lately I have been running some simulations with interFoam, in which very thin layers of fluid () in an inclined channel are involved.

As it turns out, (at least) interFoam does not like meshs with aspect ratios above a certain value (about 3), or where neighbouring cells are much bigger (probably not only interFoam's problem).

Since I stumbled upon the same problems, I decided to write a small tool to quickly (and may dirty) fix these problems:
The utility attached can:

• Store the cell volume and approximate dimensions of the cells.
  The approximation occurs since all cells are assumed to be rectangular, i.e. for coordinates ist calculated by .
  This also means that for completely rectangular meshs the approximation is exact.
• Check the cells aspect ratios based on above determined cell dimensions, and compare it to a reference value (quite similar to checkMesh).
  However, when a violation of a critical ratio is detected, the cells are stored in a cellSet, depending on the mesh direction (expressed by cell.x()). Since these cellSets distinguish between directions, they can be refined e.g. by the refineMesh tool in the dimension that is too large.
• Check the cells dimensions compared to neighbouring cells based on above dimensions or cell volume.
  Again, directions are respected and stored separately.

Results of the tool:
Either it prints "Mesh OK", or it will return a number of cellSets, namely
(x|y|z)AspectCells and (x|y|z)NeighbourCells, wherein the first store the cells with a too high aspect ratio in the respective direction, and the latter to large ratios between neighbouring cells.

Process example for my channel:

steps-1.png steps-2.png

0: Original mesh, refined using refineWallLayer
1: checkAspectRatio, refineMesh on xAspectCells
2: checkAspectRatio, refineMesh on yAspectCells
3: checkAspectRatio, refineMesh on yAspectCells
4. checkAspectRatio, refineMesh on xAspectCells
5. checkAspectRatio, refineMesh on zNeighbourCells
checkAspectRatio returns "Mesh OK"

Sadly it is an iterative process, since you always have to reselect a cellSet after the mesh has been changed, however the order of above stesps basically is irrelevant.

As an example of the results for my channel, it has changed the solution from the left (unrefined, 40550) picture to the right version (166500 cells). This process is probably far from optimal, but in my case it was right now the fastest way to solve the problem, and 166k cells is not too much:
comparison.jpg

I don't know if this tool really is useful, but I thought I'd share it. Just wmake all it, and it should work (tested in OF 2.3.x). And I'd appricate if you let me know if you can use this, or if you have any further ideas/find bugs.

Finally, here is a list of references, where I copied the code from and where I got some ideas/numbers:

Reason for this:

Jon Elvar Wallevik
http://www.cfd-online.com/Forums/ope...tml#post409745
and partially Matthew Denno, with an awesome looking result :)
http://www.cfd-online.com/Forums/ope...interfoam.html

Creating cellSets:

Tomislav Maric
http://www.sourceflux.de/blog/a-chan...t-in-openfoam/

Finding neighbours:

Su Junwei
http://www.cfd-online.com/Forums/ope...tml#post181929

Determining the (approximate) size of cell

Niels Gjoel Jacobsen
http://www.cfd-online.com/Forums/ope...tml#post275193

---
Sorry I left out the axis, I had to edit the pictures a bit. the axis directions are:

x: gropund to the right
y: ground/wall to the background
z: height