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. 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.
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.
On a separate note: I'm using Dorsal and I see that the files are built
with -DCGAL_DISABLE_ROUNDING_MATH_CHECK .
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
