dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

> Where would mesh algorithms go? They're are mainly search related,
> but are rather lengthy.

You mean TopologyComputation and BoundaryComputation? 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'?
> >
>