As someone who wrote a mesh generator (back in the 90s) my advice is that this is a can of worms you should think pretty hard about before opening. The issues, especially in 3D, get pretty complex and the work is never ending.
That being said, it would be nice to have a 2D mesh generator for general polygonal domains hooked up to dolfin. Gmsh is quite good at this but so are any number of other open source packages. (One disadvantage of CGAL, in my experience, is that error handling is not implemented very well so when it fails, which all mesh generators do from time to time, it's not handled gracefully.) For 3D my guess is that the project's time would better be spent looking at integrating an open source solid modeler whose output could be sent to a meshing package (like netgen or Gmsh). This sort of thing might be better packaged up as a fenics app rather than being part of dolfin. Cheers, Dave On Oct 17, 2013, at 8:15 AM, Garth N. Wells <[email protected]> wrote: > On 2013-10-17 15:15, Douglas N Arnold wrote: >> I think that having a basic mesh generator integrated into FEniCS >> is important for the uptake of FEniCS by new users, as well as >> for instruction. Although serious users will indeed usually need >> to construct a mesh, even for them, it is useful to have something >> quick and handy. You wouldn't consider removing UnitSquareMesh >> and UnitCubeMesh would you?. > > No - these are essential. > >> Everyone uses them all the time, >> because of the convenience of quickly getting a mesh when you want >> to focus on other things, such as testing or demoing some code. >> But rectangles are not sufficient for testing or demoing many >> things, e.g., non-uniform meshes. FEniCS has UnitCircleMesh, >> which produces a very poor mesh for most purposes (bad enough it >> may be a negative advertisement), > > Yes, it really needs to fixed. I've created a bug report: > > https://bitbucket.org/fenics-project/dolfin/issue/136 > >> so if I want to pop up a mesh >> on a curved domain, I am glad the CGAL mesh generator is there. >> Of course, there are other mesh generators, and there is >> dolfin-convert. But when introducing new users and students to >> FEniCS, the learning code is already steep, and that adds more >> things to learn. >> So I think it would be a shame to lose CGAL without replacing it >> with some other easy to use integrated mesh generator, preferably >> including the constructive solid geometry CGAL has. > > A problem with CGAL is that it doesn't really do constructive solid geometry > - it polyhedralises objects (with relative few faces) before doing CSG and > mesh generation. At present with the CGAL interface for a sphere, as the cell > size is reduced, the domain does not get closer to a sphere because what's > being meshed is a polyhedron with a low number of facets. Increasing the > number of facets in the 'polyhedral' sphere leads to CGAL mesh generation > failures. CGAL can do a good job with meshing spheres and the like via > implicit function representations, but that is awkward in combination with > polyhedra. Also, CGAL via the DOLFIN interface often produces extremely bad > meshes in 3D. > > It seems there is demand for mesh generation and CSG, so I let's remove CGAL > once an alternative with a similar interface is in place. The best > alternative is probably gmsh (operating via files or an API). Gmsh also > supports periodic boundaries and curved boundaries, which will be useful > going forward. > > Garth > > >> -- Doug >> On 10/17/2013 04:06 AM, Garth N. Wells wrote: >>> On 2013-10-17 06:42, Anders Logg wrote: >>>> On Wed, Oct 16, 2013 at 08:48:31PM +0100, Garth N. Wells wrote: >>>>> On 2013-10-16 20:17, Anders Logg wrote: >>>>> >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. >>>>> > >>>>> >It's an optional dependency, so why is it a big problem? >>>>> > >>>>> (a) the tests keep failing randomly; (b) it breaks with GCC 4.8; and >>>>> (c) updating to CGAL 3.4 is a cryptic mess. >>>> I think >>>> (a) enable the tests only on one buildbot, the one where we know it >>>> fails the least >>>> (b) + (c) try to find a replacement backend mesher (or write our own >>>> mesher) as a long-term solution >>> The question to ask is what is the purpose of built-in mesh generation?. >>> I can only think of teaching. Anything else? >>> Writing our own mesh generation would be a huge waste of time. There are >>> good mesh generators available (netgen, gmsh, etc). >>> Garth >>>> -- >>>> Anders >> _______________________________________________ >> 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
