On Monday 18 May 2009 19:43:32 Anders Logg wrote: > On Mon, May 18, 2009 at 12:07:47PM +0100, Garth N. Wells wrote: > > Andre Massing wrote: > > > Hi all, > > > > > > On Monday 18 May 2009 11:42:05 Garth N. Wells wrote: > > > > Johan Hake wrote: > > > > > On Monday 18 May 2009 09:09:25 Garth N. Wells wrote: > > > > >> Johan Hake wrote: > > > > >>> On Monday 18 May 2009 07:46:30 Johan Hake wrote: > > > > >>>> On Monday 18 May 2009 01:21:43 DOLFIN wrote: > > > > >>>>> One or more new changesets pushed to the primary dolfin > > > > >>>>> repository. A short summary of the last three changesets is > > > > >>>>> included below. > > > > >>>>> > > > > >>>>> changeset: 6181:fbd503991aa11d35c50c142aa26134fdb0888636 > > > > >>>>> tag: tip > > > > >>>>> user: "Garth N. Wells <[email protected]>" > > > > >>>>> date: Mon May 18 00:21:03 2009 +0100 > > > > >>>>> files: dolfin/log/log.cpp dolfin/main/SubSystemsManager.cpp > > > > >>>>> description: > > > > >>>>> Add call to xmlCleanupParser() in ~SubSystemsManager(). > > > > >>>>> > > > > >>>>> The means that all but one demo pass the valgrind test (at > > > > >>>>> least if MPI is disabled). > > > > >>>> > > > > >>>> Nice! > > > > >>>> > > > > >>>> We could probably add more suppressions to the dolfin_mpi.supp > > > > >>>> (and maybe rename that file because it not only contains > > > > >>>> suppressions for mpi), so the memory test also pass with mpi. > > > > >>> > > > > >>> I see now that the two main linix buildbots are all green, which > > > > > > means > > > > > > > >>> that all tests pass. These buildbots use mpi. Does the one test > > > > > > fail on > > > > > > > >>> your machine? > > > > >> > > > > >> I've only had a problem with more recent versions of OpenMPI. > > > > > > > > > > Ok. > > > > > > > > > >>> The linux64-exp reports a bunch of memory leaks, which the other > > > > > > don't. > > > > > > > >>> Me and Johannes can't figure out why. There're a lot of gts > > > > >>> related leaks, and some PETSc. This buildbot is compiled using > > > > >>> PETSc 3, > > > > > > SLEPC 3 > > > > > > > >>> and OpenMPI 1.3. > > > > >> > > > > >> I get OpenMPI 1.3 leaks and often some with GTS too. > > > > > > > > > > That would explain the mpi related reports on the linux64-exp. > > > > > Should probably expand the suppresion file for this. Johannes? > > > > > > > > > >> The GTS interface > > > > >> is so weird and poorly documented I don't if the problem is in > > > > >> GTS or DOLFIN. I suspect GTS. > > > > > > > > > > Ok, but why does not the memory test produce gts related complains > > > > > from the two other linux buildbots? > > > > > > > > No idea. If you would like to punish yourself, try figuring out how > > > > construction/destruiction works in GTS! Anders and I discussed > > > > briefly the possibility of using CGAL in place of GTS in the future. > > > > > > I started to work on that replacement, but since I just started to get > > > familiar with cgal and dolfins mesh classes, so there are some > > > questions. Anders and I thought of > > > 1. replacing current GTS functionality by CGAL, > > > 2. adding support for computing the actual intersection > > > polygon/polyhedra as two short-term goals. > > > > > > > > > AFAICS from code GTS is only used for precomputing possible > > > intersections of mesh entities via associated boxes. This seems easy to > > > replace. To benefit from other CGAL features (as needed for 2.) > > > corresponding data structures like Point_3<Kernel> or > > > Tetrahedron_3<kernel> have to be introduced. But as far as I understood > > > from the source code and article "Efficient Representation of > > > Computational Meshes" classes like MeshEntity and derivatives are freed > > > from complicated data structure storage to make everything fast and > > > geometry related stuff were transfered to MeshGeometry, which stores > > > only vertices in a contiguous array. Therefore I hesitate a bit to add > > > members like Tetrahedron_3<kernel> to corresponding Cell(Type) > > > derivatives. Don't want to mess up the whole design :-) So any rough > > > ideas, suggestions from the mesh library designer how/where to make use > > > of these structures without intruding the design (too much)? > > > > I'm not the designer of the mesh library, but I would start by creating > > GCAL data structures internally (say within an intersection detector) > > and not touching the mesh data structures. IntersectionDetector does > > this at the moment with GTS data structures. Performance is not critical > > at the start. Once we understand GCAL better we can consider how and if > > it should interact with the mesh classes. > > > > Garth > > I'll comment more on this later. Don't have time right now, but as a > general rule I'm quite sensitive to introducing new data to the mesh > classes. :-)
I thought as much! :-) That's why I 've asked, since we have to introduce new data structure *somewhere* in mesh related classes in order to benefit from CGAL. As Garth suggested I've been thinking about encapsulated CGAL related data structure within a CGAL "interface" class, so that that other classes won't be messed up in a first try-out. If we want to implement (1) concerning new members a simple container replacement for the Gnode * tree in GTSInterface is needed but for (2) classes as Point_3<Kernel> or Nef_polyhedron_3<Kernel> have to be employed to compute the actual overlap. So I am looking forward to more of your comments :-)
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
