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 <gnw20@xxxxxxxxx>"
> >>>>> 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)?
>
> 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 <gnw20@xxxxxxxxx>"
> >>>>> 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 <gnw20@xxxxxxxxx>"
> >>>>> 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
> >>>>> DOLFIN-dev@xxxxxxxxxx
> >>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >>>>
> >>>> _______________________________________________
> >>>> DOLFIN-dev mailing list
> >>>> DOLFIN-dev@xxxxxxxxxx
> >>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >>>
> >>> _______________________________________________
> >>> DOLFIN-dev mailing list
> >>> DOLFIN-dev@xxxxxxxxxx
> >>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
------------------------------------------------------------------------
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
