dolfin team mailing list archive

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

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)?). Where would
mesh algorithms go? They're are mainly search related, but are rather
lengthy.

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.

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'?
> 
> --
> Anders