2013/5/30 Anders Logg <[email protected]> > On Thu, May 30, 2013 at 06:39:07PM +0100, Garth N. Wells wrote: > > On 30 May 2013 18:23, Anders Logg <[email protected]> wrote: > > > On Thu, May 30, 2013 at 07:17:06PM +0200, Johan Hake wrote: > > >> On 05/30/2013 05:40 PM, Garth N. Wells wrote: > > >> > On 30 May 2013 16:34, Jed Brown <[email protected]> wrote: > > >> >> Johan Hake <[email protected]> writes: > > >> >> > > >> >>>> What scale is "pretty time consuming"? My laptop takes 6 > seconds to > > >> >>>> recompile PETSc with ccache after switching between disparate > branches. > > >> >>>> This hasn't been slow enough to motivate me to find an > alternative. > > >> >>> > > >> >>> 6 second would be very nice. It takes over 1 minute on my laptop, > which > > >> >>> is a pretty new i7 with 4 cores. > > >> >> > > >> >> Mine is an i7 with two cores, so it's not the hardware. > > >> >> > > >> >>> Then it seems I have problem with: > > >> >>> > > >> >>> dolfin/generation/PolyhedralMeshGenerator.cpp > > >> >> > > >> >> Oh, I see the problem. Rename the file to > PolyhedralMeshGenerator.c and > > >> >> fix the compilation errors. ;-) > > >> > > > >> > I'm surprised it took so long for "name it .c" to come up. ;-) > > >> > > >> :) > > >> > > >> > I'd settle for being able to get rid of the CGAL template hell that > is > > >> > included in PolyhedralMeshGenerator, and which requires GBs of > memory > > >> > to build a 350 line file. > > >> > > >> With Anders geometry fix in master I guess one can just un-install > CGAL > > >> and the generation module will not be compiled. > > > > > > It remains to make the Function class use the new search tree instead > > > of CGAL. When that is done, we can cut away most of the CGAL stuff. > > > Perhaps we can also find a clever way to encapsulate the parts of CGAL > > > used for mesh generation. > > > > > > > It is very handy to have the mesh generation inside DOLFIN for some > > things, e.g, teaching. > > Yes, and I don't want to create yet another project. We discussed > moving more things into DOLFIN earlier and this would be a step in the > opposite direction. So let's keep it in DOLFIN but perhaps isolate it > to a dark corner so that only a minimal amount of CGAL has to be > included and that part has minimal dependencies back and forth to > DOLFIN so it does not need to be recompiled very often. >
I don't think hiding files in a dark corner, reduces the memory requirement of the compiler :) But there may be other options. PolyhedralMeshGenerator and CSGCGALMeshGenerator3D has very overlapping functionality and could be merged to one class. The same applies to PolygonMeshGenerator and CSGCGALMeshGenerator2D (though, they are not quite as heavy to compile). The main reason that it is so memory intensive to compile these files, I think, is the fact that that we make use of two CGAL kernels. The compiler will generate two versions of at lot of the CGAL functionality related to polyhedrals. The only place where we actually need both kernels is in the copy-function that converts a polyhedron with exact numbers to one with inexact number. It would be fairly simple to define two classes, say CGALExactPolyhedron and CGALInexactPolyhedron, and define the public interface of these classes, so that it is possible to create an inexact polyhedron from an exact without having to expose the CGAL headers. This should reduce the memory requirements for each of the files significantly If no one object, I will take a look at this after the weekend. Benjamin > > > If the new geometry code is used for the search inside Function, we > > could turn CGAL off by default. > > Yes. > > -- > Anders > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
