dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 05, 2011 at 06:40:05PM +0200, Johan Hoffman wrote:
> > 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
>
> I think "smoothing" is better than "ale", since smoothing can appear in
> different contexts.

Sounds good to me.

--
Anders


> /Johan
>
> >> >>>
> >> >>
> >> >> 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.
> >
> >
> >
> >> 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'?
> >> >>>
> >> >>
> >>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>