On Fri, 31 Jan 2014 11:10:17 +0100 Benjamin Kehlet <[email protected]> wrote:
> 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. Then note that there is a newly reported failing case https://bitbucket.org/fenics-project/dolfin/issue/224/cgal-produces-degenerate-cells Jan > > 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 _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
