It's a (ugly) workaround due to the static nature of the MeshEditor
(number of vertices must be specified a priori). It could of course be
fixed by moving the geometric partitioner inside the parser, and only
opening the editor inside closeMesh().
However the nice solution would be to make the MeshEditor more dynamic.
That would also make life easier when implementing a better refinement
algorithm (for example, the recursive longest edge bisection (Rivara)
from unicorn)
I agree it would be better to make MeshEditor dynamic. The problem is
that this is not always needed. Perhaps we should add a new class
DynamicMeshEditor that can be used when one does not know the number
of vertices and cells a priori.
It could be very simple, just storing the dynamic data in suitable STL
containers and then calling MeshEditor in close().
