[CLST]

Hi,
i currently implement a mesh generator for OpenFOAM. At the moment it only creates hexahedral meshes with uniform resolution. Since the resulting meshes are quite large i would like to implement the generation of anisotropic refined meshes.
For this i need to know which types of meshes are accepted by OpenFOAM. Here http://publications.lib.chalmers.se/...173/174173.pdf the author implies (as i understand it) that OpenFOAM supports 1-irregular meshes, hence a valid mesh must satisfy the "two-to-one" rule. The problem is that he defines the "two-to-one" rule as "at most two faces per side of a cell" where as in the source that he cites (https://www.ices.utexas.edu/media/reports/1989/8901.pdf) it's defined at "at most two neighbors per edge" which allows for up to 4 faces per cell side.
Which is correct in the case of OpenFOAM?
Thanks, Claus

[wyldckat]

Greetings Claus,

I believe I understand the dilemma here:

1. 2 faces to 1 face relates to the Finite Volume Method, which OpenFOAM uses.
2. 2 neighbours for each edge relates to the Finite Element Method, which OpenFOAM doesn't use by default.

Essentially the difference is that in FVM, the fields are calculated in the centres of faces and cells, while in FEM the fields are calculated on vertexes and edges.

Best regards,
Bruno

[CLST]

Thank you very much Bruno,
this clears it up for me.
I guess its best to stick to the "2 faces to 1 face" rule so that the mesh can be used with FVM as well as FEM.

Thanks again,
Claus

[CLST]

Hi Bruno,
I have now implemented a first version of the mesh generator that creates meshes that should in theory only work with FEM since one side of a single hexahedral cell can have up to 4 neighbour cells (see attached image).
However checkMesh does not complain and the two simulations i have tested (one based on laminar interForam damBreak and the other based on incompressible simpleFoam windAroundBuildings ) also work just fine.
As far as i know both use FVM so this should actually not work.
When i use dynamic mesh refinement (interDyFoam) it will crash after some iterations with:

--> FOAM FATAL ERROR: 
Problem : edge has too few face neighbours:1(394835)
edge:61153 vertices:(17572 17573) coords:(16 0 60)(16 8 60)

    From function removeFaces::setRefinement
    in file polyTopoChange/polyTopoChange/removeFaces.C at line 881.

FOAM aborting

I guess i still have not fully understood this "two-to-one" rule.

[wyldckat]

Quick answer:

Originally Posted by CLST

When i use dynamic mesh refinement (interDyFoam) it will crash after some iterations with:

--> FOAM FATAL ERROR: 
Problem : edge has too few face neighbours:1(394835)
edge:61153 vertices:(17572 17573) coords:(16 0 60)(16 8 60)

    From function removeFaces::setRefinement
    in file polyTopoChange/polyTopoChange/removeFaces.C at line 881.

FOAM aborting

My guess is that the problem is related to not having a refinement map also ready for the simulation. Run the tutorial "multiphase/interDyMFoam/ras/damBreakWithObstacle" and then inspect the contents of the time folders to see what I mean.
I'm referring mostly to the file "*/polyMesh/refinementHistory", which provides a map of the cells that have been split into pieces, so that the dynamic mesher is able to create a map of the refinement, so that it can either refine more or for removing the refinement.

[CLST]

The error was caused by a bug in the mesh generator where some faces at the border did not use the edges of the smaller adjacent faces but created their own edges. Consequently those edges were indeed only connected to one face as the error message said. The solver's did not seem to care about it and since there were only few of such edges at the far borders were not much happened in the simulations i did not notice the bug before (actually checkMesh even reports it when executed with -allTopology).

Now everything works so far. I still need to write the refinmentHistory or wherever the dynamic mesh stores the levels of the cells so that the larger cells are refined instead of wasting all the memory on refining the small cells even further (on a first glance i would say in the cellLevel and pointLevel files ). So thanks for pointing me into that direction.

[Zaphod'sSecondHead]

Hi Claus,

I'm trying to find out if OpenFOAM supports meshes with 4 faces per cell side.

In your previous post, you mentioned that your code was working smoothly. Was this with the case of a 4:1 face ratio? - i.e., 1 face of a cell being adjacent to 4 faces of another cell?

Thanks.

[CLST]

Hi Saumitra,
yes OpenFOAM supports 4 faces per cell side.
I found out that a more popular name for the two-to-one rule in the context of octrees is 2:1 balance which basically says that the level of two adjacent nodes in the octree must not differ by more than one.
This paper contains a good definition: Bottom-up construction and 2: 1 balance refinement of linear octrees in parallel

My mesh generator uses a variant of the algorithm in that paper.
I have used the generated meshes in the two simulations mentioned before without problems.

As far as i know the finite volume method does not impose a limitation on the number of faces that can be adjacent to a single face.
The two-to-one rule is not mentioned in the OpenFOAM-Guide only in some comments in the source code for dynamic meshes (e.g. hexRef8.C).
It might as well be that OpenFOAM supports more than 4 faces per cell side but i haven't tried it yet.

Greetings
Claus

[Zaphod'sSecondHead]

Yes it seemed quite odd for there to be a restriction on the number of faces per cell side for FVM. Nevertheless, thank you for the clarification!