On 31/01/2014 10:49, Garth N. Wells wrote:
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.
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 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.
Ideally you provided us (= CGAL) with data sets where you
observe crashes. Then we can work on it, give advice what
to do as a user, or explain you why we can't mesh it.
andreas
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
--
Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project
phone: +33.492.954.912 skype: andreas.fabri
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
