dolfin team mailing list archive

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

On 04/04/11 14:59, Anders Logg wrote:
> On Mon, Apr 04, 2011 at 12:38:26PM +0100, Garth N. Wells wrote:
>>
>>
>> On 04/04/11 12:23, Anders Logg wrote:
>>> On Wed, Mar 16, 2011 at 07:42:35AM +0000, Garth N. Wells wrote:
>>>>
>>>>
>>>> On 15/03/11 20:56, Anders Logg wrote:
>>>>> On 15 March 2011 20:49, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>>>>>>
>>>>>> The number of Mesh members functions is getting pretty large, as too is
>>>>>> the number of classes in the dolfin/mesh directory. This is likely to
>>>>>> grow as more search, parallel and refinement features are added. Is it
>>>>>> therefore sensible to:
>>>>>>
>>>>>>  - Move mesh algorithms (search, refine, generate, etc) to a separate
>>>>>> directory?
>>>>>
>>>>> Yes, we can have one directory for each set of algorithms related to
>>>>> the Mesh class. We already have 'ale' and 'adaptivity' which contain
>>>>> Mesh algorithms (+more).
>>>>>
>>>>
>>>> OK. Any directory name suggestions?
>>>
>>>   mesh          data structures (Mesh class and friends)
>>>   ale           algorithms for mesh smoothing
>>>   refinement    algorithms for mesh refinement
>>>   partitioning  algorithms for mesh partitioning
>>>   coloring      algorithms for mesh coloring
>>>
>>
>> Some of the above won't contain much and could be merged (e.g. coloring
>> could go into partitioning (possibly renamed to graph)?).
> 
> Sounds good. But "graph" sounds a bit misleading.
> 

Not for colouring and partitioning - both build a graph from a mesh
input and partition or colour the graph.

>> Where would mesh algorithms go? They're are mainly search related,
>> but are rather lengthy.
> 
> You mean TopologyComputation and BoundaryComputation? 

No, I mean the CGAL wrappers.

Garth

> Yes, they could
> also go in a separate directory but would also just be very few
> classes. Are there others in addition to those two?
> 
>> I suggest also eventually adding a 'geometry' directory. With a geometry
>> representation, we can use CGAL to do some mesh generation, and we can
>> do better refinement  - conforming to the real geometry rather than the
>> coarsest polygon.
> 
> Sure. There's a blueprint on a complete rewrite of the mesh
> refinement, ideally based on some external library. It's slow, doesn't
> work in parallel plus it's broken...
> 
> --
> Anders
> 
> 
>> Garth
>>
>>>>>>   - Remove 'algorithmic' functions from Mesh, and make them members of
>>>>>> static classes or free functions (as we've done for refine)? Mesh would
>>>>>> then be just a data structure.
>>>>>
>>>>> Yes, perhaps some of the functions can be removed, but it's nice to
>>>>> have shortcuts so one does not have to know where a certain algorithm
>>>>> is located. For example mesh.snap_boundary() is easier than
>>>>> MeshSmoothing::snap_boundary().
>>>>>
>>>>>> The names of some search-related Mesh member functions are a bit
>>>>>> complex. Can we simplify them, e.g.
>>>>>>
>>>>>>     void all_intersected_entities(const Point& point,
>>>>>>                                   uint_set&  ids_result) const;
>>>>>>
>>>>>> to
>>>>>>     void intersected_cells(const Point& point,
>>>>>>                            uint_set& ids_result) const;
>>>>>>
>>>>>> and
>>>>>>
>>>>>>     int any_intersected_entity(const Point& point) const;
>>>>>>
>>>>>> to
>>>>>>
>>>>>>     int intersected_cell(const Point& point) const;
>>>>>
>>>>> Yes, I didn't make up those names. :-)
>>>>>
>>>>>> (or int isupport_cell(const Point& point) const;).
>>>>>
>>>>> I didn't get that one.
>>>>>
>>>>
>>>> The first 'i' shouldn't be there. This name is modelled on naming that
>>>> Marie introduced in her branch. The question is whether or not it's
>>>> correct to say that a point can intersect a cell?
>>>
>>> Agree with the above. Let's rename to
>>>
>>>   intersected_cells
>>>   intersected_cell
>>>
>>> I don't know of a better name than 'intersect'. Perhaps 'incident'?
>>>
>>