dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

--
Anders