dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> 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];

Yes, I like that. Then we agree on just keeping the reduced representation
of the hierarchy (base mesh + refinements), which also corresponds to the
data structure used in Bey's paper, with also the functionality of
returning a full representation of any mesh in the hierarchy.

/Johan

>
> ?
>
> /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
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>