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. > Where would mesh algorithms go? They're are mainly search related, > but are rather lengthy. You mean TopologyComputation and BoundaryComputation? 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
