dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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).

>   - 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.

--
Anders