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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
