dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Jan 16, 2011 at 06:14:13PM +0100, Anders Logg wrote:
> On Sun, Jan 16, 2011 at 10:30:40AM +0000, Garth N. Wells wrote:
> > On Jan 16 2011, Anders Logg wrote:
> >
> > >On Sat, Jan 15, 2011 at 04:42:51PM +0000, Garth N. Wells wrote:
> > >>I would like to suggest that we be more explicit with respect to what is
> > >>in MeshData, for example not putting parallel and coloring related data
> > >>into the maps, but having them appear explicitly. I don't see the sense
> > >>in using maps for data that DOLFIN will always have (according to the
> > >>comment in MeshData.h):
> > >>
> > >>  /// The following named mesh data are recognized by DOLFIN:
> > >>
> > >>I'm finding it awkward and error prone to generalise the coloring of
> > >>mesh entities using the present MeshData approach.
> > >
> > >I think that's the main strength of the MeshData class, that it's easy
> > >to expand. New data can be created on demand and it doesn't take up
> > >any space if the data is not needed. It also doesn't clutter the
> > >interface with lots of extra functions.
> > >
> > >Is there anything in particular that is difficult to store in
> > >MeshData?
> > >
> >
> > Yes, the colouring data. It's natural to associate a triplet
> > (coloured dim, neighbour dim, distance) with a collection of
> > vectors/arrays, and putting this in a string is clunky, especially
> > with multiple colourings. It's technically possible, but the code
> > becomes very confusing and a pain to implement.
>
> Yes, I admit it's a bit awkard to have to create the strings.
>
> > >An alternative approach would be to create
> > >
> > > BoundaryData
> > > ParallelData
> > > ColoringData
> > >
> > >and store pointers to those in MeshData. Then the first time they are
> > >requested by
> > >
> > > mesh.data().coloring()
> > >
> > >the pointer is created.
> > >
> > >But I would really like to avoid that. Another reason for keeping the
> > >current design is that by relying on simple arrays, it's all
> > >automatically stored as part of the DOLFIN XML format which can
> > >read/write MeshData, including whatever stuff we throw in there.
> > >
> >
> > That's fine for throwing in new stuff, but if we start from the
> > point that every mesh is distributed and possibly coloured, then
> > handling the parallel and coloring data is simple.
>
> Yes, perhaps when data becomes essential enough (when it's no longer
> "auxiliary"), we move it out of MeshData into a separate container.
>
> I suggest
>
> class Mesh
> {
>
> private:
>
>   MeshTopology _topology;
>   MeshGeometry _geometry;
>   MeshData _data;
>   ParallelData _parallel_data;
>
> }
>
> We could also have
>
>   ParallelData* _parallel_data;
>
> and let that pointer be zero until it's requested the first time so we
> don't store extra data that is strictly not necessary (since we've
> made it a point that our Mesh class requires minimal storage).
>
> That would be easily handled:
>
> ParallelData& Mesh::parallel_data()
> {
>   if (!_parallel_data)
>     _parallel_data = new ParallelData(*this);
>   assert(_parallel_data);
>   return *_parallel_data;
> }

I'm working on a new class ParallelData. I will submit a sketch
shortly and then you can adjustments to it.

--
Anders