dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

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.

--
Anders