dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 04, 2011 at 03:03:21PM +0100, Garth N. Wells wrote:
>
>
> On 04/04/11 14:59, Anders Logg wrote:
> > 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.
> >
>
> Not for colouring and partitioning - both build a graph from a mesh
> input and partition or colour the graph.

ok.

> >> Where would mesh algorithms go? They're are mainly search related,
> >> but are rather lengthy.
> >
> > You mean TopologyComputation and BoundaryComputation?
>
> No, I mean the CGAL wrappers.

I meant to add a directory 'intersection' to the above list. Yes,
they should definitely go in a separate directory.

I can begin with some of this tonight.

--
Anders


> Garth
>
> > 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...
> >
> >> 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'?
> >>>
> >>
>