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