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