On 2014-01-31 10:10, Benjamin Kehlet 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.
Yes, I agree. It dilutes the focus for DOLFIN to also be in the business
of sophisticated 3D mesh generation. A separate project that wraps good,
open-source generators and provides a DOLFIN interface could be more
focussed.
Garth
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
