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 > > > > > > > > > Garth > > > > > Johan > > > > > >> Garth > > >> > > >>> Johan > > >>> > > >>>> I have run the memory test on the la/unit/python/test.py and I know > > >>>> that there are some issues with the hand made python wrapper of the > > >>>> data() functions for matrices. (I fixed this, but forgot to > commit it > > >>>> and now an hg update -C has removed it.) Will look at it again... > > >>>> > > >>>> I also spotted some memory leaks in the Epetra backend, > especially in > > >>>> the SparsityPattern class. > > >>>> > > >>>> Should we also run the unit tests through the memory tester? > > >>>> > > >>>> Johan > > >>>> > > >>>>> Calling xmlCleanupParser() may cause problems if DOLFIN is > > >>>>> called from another program/library which uses libxml2 and > > >>>>> dolfin::~SubSystemsManager is called while the other program is > still > > >>>>> parsing XML files. > > >>>>> > > >>>>> > > >>>>> changeset: 6180:e53531014e9b3a7859969859c1dd810563424a29 > > >>>>> user: "Garth N. Wells <[email protected]>" > > >>>>> date: Mon May 18 00:10:19 2009 +0100 > > >>>>> files: dolfin/log/log.cpp > > >>>>> description: > > >>>>> Use much simpler solution for leak in plot.cpp. > > >>>>> > > >>>>> Use smart pointer boost::scoped_array in place of plain array. > > >>>>> > > >>>>> > > >>>>> changeset: 6179:a8e6beebe5f513687a07d2bf0d652cd83b147f41 > > >>>>> user: "Garth N. Wells <[email protected]>" > > >>>>> date: Sun May 17 23:51:07 2009 +0100 > > >>>>> files: dolfin/fem/DofMap.cpp dolfin/fem/DofMap.h > > >>>>> dolfin/function/FunctionSpace.cpp dolfin/log/log.cpp description: > > >>>>> More DofMap clean up. > > >>>>> > > >>>>> > --------------------------------------------------------------------- > > >>>>>- For more details, visit http://www.fenics.org/hg/dolfin > > >>>>> _______________________________________________ > > >>>>> DOLFIN-dev mailing list > > >>>>> [email protected] > > >>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > > >>>> > > >>>> _______________________________________________ > > >>>> DOLFIN-dev mailing list > > >>>> [email protected] > > >>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > > >>> > > >>> _______________________________________________ > > >>> DOLFIN-dev mailing list > > >>> [email protected] > > >>> http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > _______________________________________________ > > DOLFIN-dev mailing list > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
