On 10/16/2013 08:53 PM, Garth N. Wells wrote:
On 2013-10-16 20:27, Mikael Mortensen wrote:
Den Oct 16, 2013 kl. 9:17 PM skrev Anders Logg:
On Wed, Oct 16, 2013 at 01:00:08PM +0100, Chris Richardson wrote:
On 16/10/2013 09:25, Garth N. Wells wrote:
Does anyone have an opinion on keeping or removing CGAL from DOLFIN?
Below are some pros and cons:
- CGAL makes DOLFIN slow to build and builds use a lot of memory.
- CGAL is unpredictable in throwing errors (predictable in that it
will throw cryptic errors, unpredictable when or with which
compiler).
- CGAL is difficult to understand and the latest version has very
cryptic interface changes.
- Almost all of the random DOLFIN buildbot failures are due to CGAL
mesh generation failures.
+ CGAL provides mesh generation for a variety of simple shape
combinations (the DOLFIN interface to CGAL is not rich enough for
anything serious).
Agreed. Anyone serious will make their mesh independently, so CGAL
is really just an annoying toy in this context... (!)
That may be true, but simple also has a use.
I find the meshing of nontrivial shapes come in very handy in
teaching. It looks much more impressive when I'm solving the Poisson
equation on a combination of circles and pipes...
Teaching is the only benefit that I see (although an issue is that
sometimes your meshes will be randomly screwed up). A possibility
would be to make CGAL generation of DOLFIN meshes a 'fenics-app' that
can be pulled in and periodically tested by users to alleviate the
burden it places on DOLFIN development.
I haven't used CGAL with DOLFIN (aside from debugging, and not in a
couple of years). However, when trying to find a robust volumetric
meshing library for other purposes, the only real option was CGAL
(suggestions appreciated here) - as far as I could tell, the choices
were Netgen (I found stability to be highly sensitive to the input
surface mesh), Tetgen (not strictly FOSS - academic use only, so *GPL
incompatible) and CGAL. The vast majority of more general tools seemed
to use one of the three as a backend. As such, I only have experience
working with CGAL 4.2, but I can see how a user may need to take a
surface mesh during execution and do a full volumetric re-mesh if some
criterion is met. But then, a wrapper to convert a CGAL mesh object to a
DOLFIN one & v.v., combined with CGAL's Python bindings, might be a
straightforward way around providing direct support. In any case, I
don't know what the support for 3D meshing is like in 3.x
This is not a particular point either way, just keen to add to the
discussion. Back in 2009-11, I remember CGAL primarily for being a PITA
during fresh Dorsal builds (mine, at least), but I can see more uses
than teaching. The 'fenics-app' idea sounds reasonable, but if it is
challenging to maintain compatibility with other development when it's
part of the default build, I suppose that would be an even bigger task
when only "CGAL App" folks are accounting for it. However, if it's
holding back development, I don't know how many are actually currently
using it with DOLFIN - I can't say I am.
Phil
Garth
Mikael
It's an optional dependency, so why is it a big problem?
--
Anders
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
--
__________________________
Phil Weir | NUMA Engineering Services Ltd.
The Business Centre, Blackthorn Business Park, Coe's Road, Dundalk, Co. Louth,
Ireland.
Tel: +353 42 9395821 | Fax: +353 42 9390220
_______________________
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
