dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

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