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 <[email protected]> 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 : [email protected] > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
