Allow MeshFunctions to have "string" values as well as bool, int, etc.

[Chris Richardson]

In order to specify multiple boundary conditions, to avoid confusion, it is often convenient to label geometry with a string rather than a number.

Propose adding strings to MeshFunction template types, which would internally be int with a lookup table/map.

[Martin Sandve Alnæs]

Where would that be used? The concept of integer subdomain ids spans UFL, UFC, assembler, DirichletBC, possibly more. It's better to just handle strings as a layer on top in user programs:

markervalues = dict(foo=1, bar=3)
boundary.mark(meshfunction, markervalues["foo"])
M = f*dx(markervalues["foo"])

The user layer can use tuples:

markervalues = dict(foo=(1,3), bar=(2,3))
boundary.mark(meshfunction, markervalues["foo"])
M = f*dx(markervalues["foo"])

an approach which would be more functional if tuples of subdomain ids were accepted in all places, see the comments in this deprecated issue:

https://bitbucket.org/fenics-project/dolfin/issues/87/submesh-of-multiple-subdomains

[Jan Blechta]

Agree with @martinal. Not that it would not be possible, but it would create a big additional maintenance burden.

[Chris Richardson]

I guess the idea is that it should be possible to track surfaces with human readable names, and actually, it is perhaps more important that this goes into a file format. It can all be done with user code, but could be a nice feature to add to HDF5/XDMF for example.

[Prof Garth Wells]

What we need is a better way to associate names with parts of the mesh. Under-the-hood we can (and should) use integers.

Some problems have 10s or 100s of boundary and/or domain markers; it is really error prone using integers. It is important to get string names into the file format, and at the DOLFIN level we need a simple way to map from a string to the the integer marker.

[Martin Sandve Alnæs]

I've yet to see any ideas here that cannot be solved by using dictionaries or just regular variables holding marker values in the user level code. Until I see a low-effort concrete suggestion I'll stick to preferring user level solution, perhaps by adding a demo showing how to do it cleanly.

Which file format are you talking about? The MeshFunction? That would add features to the MeshFunction interface that don't make sense for most types of MeshFunction.

[Prof Garth Wells]

Dictionaries/maps can be used at user level, but they need to be populated somehow. Reading in a huge mesh with hundreds of boundaries marked by integers is not manageable and leads to mistakes.

What I would like are named subdomains (issue title is perhaps not a good reflection of the intent). We could then add functionality to build integer MeshFunctions from this to be able to work with the current assemblers.

[Chris Richardson]

@garth-wells - feel free to edit the title - I'm often a bit off topic.

[Martin Sandve Alnæs]

Related to this, I would like the issue of subdomains stored with the Mesh to be resolved. The Mesh.domains() situation is not very nice, the objects can be carried with the Mesh but are not used in the assembler. The reason for placing them in Mesh is related to the issue under discussion: loading subdomains together with the mesh from a file. If file readers return multiple objects, i.e. the mesh, the meshfunction(s), and a marker value dict something like {tdim:{name: integer_ids_tuple}}, maybe Mesh.domains() can be removed?

[Chris Richardson]

I would certainly vote for removal.

[Prof Garth Wells]

Maybe we can get rid of the >> syntax for files as part of this too!

What if we treat an XDMF file as a handle that can be inspected and from which data can be pulled out, e.g.

xdmf0 = XDMFFile("filename.zdmf")

# Print top-level paths
print(xdmf.get_paths(0))

# Get handle to 'mesh0' path
xdmf0 = xdmf.path("mesh0")

# Get the mesh
mesh = xdfm0.get_mesh()

# Get associated mesh functions
mf0 = xdfm0.get_mf("bar0")
mf1 = xdfm0.get_mf("bar1")

[Anders Logg (Chalmers)]

Removing milestone: 1.8 (automated comment)