dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

On Monday 18 May 2009 19:43:32 Anders Logg wrote:
> 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. :-)

I thought as much! :-) That's why I 've asked, since we have to introduce new 
data structure *somewhere* in mesh related classes in order to benefit from 
CGAL. As Garth suggested I've  been thinking about encapsulated CGAL related 
data structure within a CGAL "interface" class, so that that other classes 
won't  be messed up in a first try-out. If we want  to implement (1) concerning 
new members a simple container replacement for the Gnode * tree in 
GTSInterface is needed but for (2) classes as Point_3<Kernel> or 
Nef_polyhedron_3<Kernel> have to be employed to compute the actual overlap.

So I am looking forward to more of your comments :-)