dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature