Error when reading Gmsh mesh with overlapping physical groups

I/O
, , ,
1

I’m trying to use physical groups for various different materials, as well as regions with a non-zero source term in Poisson’s equation. Consequently, regions with a source term are part of multiple physical groups. However, trying to read this mesh using DOLFINx v0.9.0 (from conda-forge) results in the error:

malloc(): mismatching next->prev_size (unsorted)

Here is a minimal working example:

import gmsh
from dolfinx.io import gmshio
from mpi4py import MPI

gmsh.initialize()
gmsh.option.setNumber("General.Terminal", 0)  # suppress terminal output

gmodel = gmsh.model()
gmodel.add("model1")

gmodel.occ.addBox(0, 0, 0, 1, 1, 1, 1)
gmodel.occ.addBox(1, 0, 0, 1, 1, 1, 2)
gmodel.occ.addBox(2, 0, 0, 1, 1, 1, 3)
gmodel.occ.removeAllDuplicates() # remove duplicate surfaces and edges
gmodel.occ.synchronize()
gmodel.addPhysicalGroup(3, [1, 2], 1, "vol1")
gmodel.addPhysicalGroup(3, [2, 3], 2, "vol2") # entity (3, 2) is in both physical groups
gmodel.mesh.generate(3)

mesh, cell_markers, facet_markers = gmshio.model_to_mesh(gmodel, MPI.COMM_WORLD, 0, gdim=3) # error

gmsh.finalize()

Writing the mesh to a .msh file and reading it using dolfinx.io.gmshio.read_from_mesh() results in the same error. Defining the physical groups such that entity (3, 2) isn’t in both physical groups eliminates the error.

Is there no way to handle overlapping physical groups in DOLFINx? What is the best way to tag regions that may overlap? I’m hoping not to have to create disjoint physical groups.

2

That’s simply not allowed, see add checks of cell tag consistency in gmshio by pierricmora · Pull Request #3342 · FEniCS/dolfinx · GitHub (not merged yet).

1 Like
3

Thanks francesco, that’s what I figured after doing some digging. I could assign unique physical groups to each overlap region, but this would be a last resort if there is no other good way.

To get around this issue, I thought about propagating the tags from gmsh elements to dolfinx cells manually, without actually defining overlapping physical groups. However, this doesn’t seem easy because dolfinx “shuffles” the cell and vertex indices upon importing the gmsh mesh. Is it possible to calculate the permutation that maps gmsh cell indices to dolfinx cell indices (as well as the permutation for vertices)?

4

Seems too complicated to me. If you have two groups 1 and 2, simply tag 3 as the group that has both groups. Why are you trying to avoid doing that?

5

My actual problem can have many groups for different materials as well as different source terms. Assigning unique tags to each pair of material and source term can increase the number of physical groups manyfold. It also makes things like defining integration measures within individual materials later on a bit more complicated.

These are not unsolvable problems, I’m just looking for a neater solution. Having the gmsh to dolfinx cell index permutation would make things easy. If getting this is not straightforward, then I will likely resort to defining disjoint physical groups as you suggest.

6

Note that you can supply tuples in integration measures, ie.

dx((5,7)) will integrate over all cells marked with either 5 or 7.

An example for a more complex mesh is shown

See: Renumbered .msh imported data giving wrong subdomains - #4 by dokken

1 Like
7

Thank you Jørgen, I wasn’t aware that integration measures can be called with tuples, that does make things a little easier. Thanks for the example as well.

For now, instead of defining lots of disjoint physical groups to resolve all overlaps, I’ve taken the approach of carrying over source term tags from gmsh to dolfinx myself, to eliminate overlaps. Namely, I compute the permutation that maps gmsh element indices to dolfinx cell indices (using cell vertex coordinates), and use that to get the list of dolfinx cells corresponding to each source term. This works well for a 3D mesh with only tetrahedral elements, but could get more involved for more complicated problems with different element types.