2014-01-31 Garth N. Wells <[email protected]>: > On 2014-01-31 08:01, Marco Morandini wrote: >>> >>> Yes, I suggest moving the mesh generation part to a separate >>> component. This will remove CGAL completely from Dolfin, since CGAL is >>> now used only for mesh generation. >>> >>> This new component will depend on Dolfin. We (ie. Johannes :-) ) will >>> generate Debian/Ubuntu packages and provide a dorsal .package file, so >>> installation shouldn't be more complicated than before this split. >>> >>>> From a users perspective the changes should be minimal (an extra >>> >>> import in python). Maybe Dolfin can try to import the module to >>> provide backward compatibility for a while? >>> >>> Even if this opposes the ongoing effort to reduce the number of >>> components in FEniCS, I think it is the best solution for now. >>> >>> Anders suggested the name "mshr" which I think is cool. A very >>> preliminary version (without python support yet) is here: >>> https://bitbucket.org/benjamik/mshr/ >>> >>> Opinions? Objections? >> >> >> Personally, I fear that this component will quickly bitrot if left >> separated from dolfin. > > > This is a danger. It has proven very difficult for projects to survive > outside of the core packages. For it succeed, it would need to become an > 'official' package with a sufficiently large group of core contributors.
To some extent this is also a danger within Dolfin. The current 3D implementation is messy implemented and not very robust. > > >> And I don't completely grasp the rationale >> behind the change: you someone want a quick build why don't configure >> without CGAL? The net effect would be the same: dolfin without CGAL. >> > > There are the practical aspects of building, and the problem that the > implementation is half-baked and fragile. Given the difficulty of mesh > generation as a stand-alone problem, I do see advantages in spinning it out > as a separate package. > > A separate package could provide a common interface to a few generation > libraries (CGAL, Gmsh, netget), each of which has strengths for particular > types of problems That is on the TODO list. Tetgen is an obvious candidate as well. > > >> That said, I think that what is really important is that >> the kind of application sketched in >> >> http://fenicsproject.org/pipermail/fenics/2013-October/000685.html >> >> will still work without requiring writing and reading data to disk. >> > > This won't be a problem if mshr has a dolfin::Mesh interface. > > >> On a separate note: I'm using Dorsal and I see that the files are >> built with -DCGAL_DISABLE_ROUNDING_MATH_CHECK . >> > > This option is not used on the buildbots, and they see periodic CGAL meshes > crashes. My experience is that CGAL meshing is solid for smooth 3D volumes > defined by implicit surfaces, but very fragile for polyhedra, with > robustness falling away as the number of facets increases. In my experience crashes have been due to errors on my side, typically attempting to mesh a polyhedron containing self intersections. Benjamin > > Garth > >> Fabri, couldn't be this the cause of the random meshing failures >> the developers are experiencing? >> Shouldn't the files that include CGAL headers built without this flag >> and with -fexcess-precision=standard instead? >> Has this been discussed before? >> >> Marco >> >> >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
