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.
