Implement a MeshView class

[Prof Garth Wells]

Implement a MeshView class that will have both local and parent indexing, but sits on top of a Mesh. This will permit the construction of dofmaps with different equations on different domains, amongst other things.

This may share features if SubMesh, but the name at least will make clear what it does.

[Prof Garth Wells]

Related issues:

• https://bitbucket.org/fenics-project/dolfin/issue/87
• https://bitbucket.org/fenics-project/dolfin/issue/137

[Martin Sandve Alnæs]

Bumping this up, I'd like to make it a priority and get started implementing it soon.

[Anders Logg (Chalmers)]

MeshView sounds like a good idea.

[Prof Garth Wells]

I need it soon too.

[Prof Garth Wells]

I've been thinking a bit about this, and wondering if

• MeshView should be a subclass of Mesh; or
• if we need a new mesh base class, e.g. BaseMesh, of which Mesh and MeshView are subclasses.

Assemblers, for example, would take a BaseMesh object. I think it would be cleaner to have BaseMesh, but I wonder if the overhead of virtual function calls would be an issue?

It would be natural if Mesh has a constructor/creation function that takes a MeshView and turns a view into a full-fledged mesh.

[Anders Logg (Chalmers)]

I think at least this should be tested before introducing virtual function calls. A lot of effort went into making the mesh data (topology + geometry) quick to access by direct access to plain C arrays via inlined interface functions.

I would think that a virtual function call might destroy that.

[Martin Sandve Alnæs]

Another possible advantage of a BaseMesh interface would be to allow creation of a NonaffineMesh for parameterized (high order) geometries instead of adding a coordinate element or degree to the current Mesh.

[Chris Richardson]

I've started some experimentation with MeshView in a branch chris/meshview-expt.

I just wanted to find out what kind of issues would arise, really, so please comment freely. I decided to use Mesh as a base class, because it will be nice to be able to use the same MeshEntityIterator and I/O for MeshView as for Mesh. Essentially, it is a Mesh, but one which has a reference to another "main" Mesh.

I started from the idea that the MeshView is just a list of entities (of a given topological dimension) on a Mesh.

It needs to have its own MeshTopology (fairly easy to construct), but it can share the MeshGeometry (or part of it).

In parallel, it can get quite tricky - calculating global vertex indices. Some processes may end up with no cells, but still sharing some vertices.

[Anders Logg (Chalmers)]

Removing milestone: 1.7 (automated comment)