Handling IO of meshes with impaired topology

[Nico Schlömer]

Reading the attached mesh passes fine although there is an alone vertex:

from dolfin import *
mesh = Mesh('test.xml')
mesh.init(0, 2)
print(Vertex(mesh, 0).num_entities(2))

gives 0. This isn't usually desirable and can result in hard to debug problems at later stage, e.g. preconditioner setup, see #838.

[Jan Blechta]

Stripped down unnecessary complexity of the report.

[Prof Garth Wells]

I don't think this is a bug. It's a valid mesh, just not one you would normally want to use.

DOLFIN has the tools available for users to perform checks if they think they may have a defective mesh. The user needs to decide what counts as defective and what tests they may want to apply.

[Nico Schlömer]

Errors that stem from meshes with vertices that don't have element connectivity are very hard to debug because they appear much further down the line, e.g., when trying to solve a preconditioned system (see #838).

For this reason I would have suggested to turn on sanity checks by default, and have an option to turn them off if you really want a mesh like that.

[Jan Blechta]

@nschloe, I would suggest submitting a pull request so that it gets tested that no reasonable use case is broken and the check is sufficiently lightweight, i.e., local. Maybe you sway Garth's opinion that way.

Introducing a new option for that is a burden. An option owned by mesh topology object, or maybe by mesh building infrastructure, seems like a heavy-weight change, considering there is no good API for that, as far as I remember. (Might be easy to do when #67 is resolved.) I think that an appropriate warning would make this an easily debuggable problem.

[Prof Garth Wells]

I wouldn't personally recommend putting time into a PR just yet.

There are a number of issues:

1. What constitutes a defective mesh? (isolated vertex, isolated cell, detached groups of cells, vertex-vertex cell connections, degenerate cells. . . . )
2. Computing connectivities is an expensive operation (time and memory) and should not be done silently when not required.
3. Meshes are typically created once and read many times after that. There should be no default non-trivial checking of a mesh that is known to be good.
4. The best stage to perform checks is at mesh generation and/or mesh format conversion. It's a one-off cost, and generation is the point at which issues can be fixed.
5. Mesh checks can be performed independently of the runtime solution, i.e. carefully checked before launching simulations. For this very purpose we added functionality a while back to DOLFIN to produce histograms of cell quality for inspection before applying iterative solvers. Obviously, we only want to do these checks once and not every time the same mesh is read (some of these meshes are approaching 1B cells). (We have pushed back on the supplier of the meshes to perform their own checks since at generation phase they can fix quality issues.)

[Nico Schlömer]

Thanks everyone for your thoughts.

I'll be happy to let this issue lie. I've fixed the mesh in my code, and I guess we can always come back to it if it turns out to be a problem for other people one day.