dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #04074
Re: MeshHierarchy
On Tue, Dec 19, 2006 at 04:01:02PM +0100, Johan Hoffman wrote:
> > 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).
>
> Good.
>
> > 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.
>
> Ok.
>
> >> 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?
>
> Yes, we could do that. In either case one should be able to ask for mesh_k
> and get a complete mesh object by assembling the "leaf cells" of meshes
> m<k, with the leaf cells being cells without children.
>
> /Johan
Good idea, then maybe we don't need the alternative full
representation. How about something like this (which is sort of what
we had in the old MeshHierarchy):
class MeshHierarchy
public:
Mesh operator[] (uint i) const;
}
So one can do
MeshHierarchy hierarchy;
Mesh mesh = hierarchy[3];
?
/Anders
>
>
>
>
>
> > /Anders
> >
> >
> >> Any other ideas/comments/objections?
> >>
> >> /Johan
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> >
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
Follow ups
References