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