dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jan 17, 2011 at 10:00:06AM +0000, Garth N. Wells wrote:
>
>
> On 17/01/11 09:58, Anders Logg wrote:
> > 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.
> >
>
> It may be worth considering something that is more than just data, but
> can also provide some communication functionality, etc.
>
> Garth

Sure, we can extend the class with all functionality we need. If it
turns out it's more that ParallelData, we can change the name to
something more appropriate.

--
Anders