Develop a MeshRefinement or MeshHierarchy object

[Chris Richardson]

At present, refinement is done through static functions. It might be better to have an object which can be used to perform refinement, with more user control over the process.

[Patrick Farrell]

A minor comment: firedrake has started implementation of a MeshHierarchy object, along with FunctionSpaceHierarchy and FunctionHierarchy for use in geometric multigrid methods. It might be worth looking at their syntax for inspiration -- they're probably in a state where their syntax could be changed if the replacement were obviously superior.

[Marie Elisabeth Rognes]

Ah, thanks for the info! How does these abstractions compare to the dolfin.Hierarchical design?

[Lawrence Mitchell]

They're currently just "bags" of meshes, function spaces and functions respectively. With the mesh bag maintain a parent->child cell relationship, the function space bag providing a map from parent cells to child dofs and the function bag providing MG operators (restriction/prolongation/injection). In particular, although it's a good idea, it's the bag that knows about the parent child relationships: so when you pull something out of a bag you can't inspect it to determine that it comes from a hierarchy.

[Martin Sandve Alnæs]

Storing the parent child relations in the function etc complicates these classes, I intuitively like the "separate bags" design better. In addition to cleaner separation of concerns, it allows cleaner separate handling of multiple refinement chains with some shared coarse objects but refinement in different places.

[Prof Garth Wells]

Yes, separation is much better. It's a constant battle to unpick the complexity in the mesh class when it stores data unrelated to the essentials of the mesh itself.