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. :-) -- Anders > > > > > > > > > > > > > > > > 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
