dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22055
Re: Mesh questions
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
Follow ups
References