dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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


> --
> Anders