dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Dec 19, 2006 at 02:59:29PM +0100, Johan Hoffman wrote:
> I am now working on mesh refinement/coarsening in Dolfin. There are 2
> different approaches; either (1) we have one mesh object that we modify,
> or (2) we have a hierarchy of meshes. I think we should support both (1)
> and (2). The benefit of (1) is that it is simple and cheap to store,
> whereas (2) can make coarsening simpler and is typically needed in
> geometric multigrid.
> 
> I plan to add a class MeshHierarchy for the purpose of (2). I want to keep
> it simple, but to minimize storage we need to be somewhat more clever than
> just using a simple array with meshes. I guess something like (i) a
> primitive base mesh; mesh0, which is a regular mesh object, together with
> (ii) the number of refinement levels, and (iii) for each level k the cells
> that are part k but not k-1, together with their vertices and edges.

Sounds good. The mesh class should support this without difficulty
(storing a mesh that is not connected).

The mapping from one level to the other can use the class MeshFunction
in the same way that it is currently used to map entities on a
boundary mesh to the original mesh.

> Is there any problem in considering (iii) to be some sort of "broken
> mesh", and treat mesh_k as a regular mesh object that may not be
> connected? If we do this then MeshHierarchy would basically just be a
> collection of mesh objects, together with parent-child info.

So the parent-child info could be a MeshFunction.

I think there should also be some functionality for storing the entire
hierarchy so that each mesh in the hierarchy is a complete
representation. Maybe there could be a flag to choose how the
hierarchy is stored?

/Anders


> Any other ideas/comments/objections?
> 
> /Johan