dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

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