dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, May 19, 2009 at 08:49:26AM +0200, Andre Massing wrote:
> 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 :-)

New data can be in at least two ways without needing to modify the
basic mesh data structures (MeshTopology and MeshGeometry):

1. It can be stored in a separate class, like we already have now in
the Mesh class where the additional data needed to detect
intersections is stored in a class IntersectionDetector (which is a
bit weird since IntersectionDetector is really an algorithm, not
data).

2. It can be stored as auxiliary data in the data section of a Mesh.
A mesh has a MeshData member which can contain an arbitrary number of
MeshFunctions and arrays (std::vector). Each datum associated with a
name.

If you want to store CGAL data, it's probably better to do it using
option (1). But the important point is to add it as auxiliary data
which takes no space until it is needed.

-- 
Anders

Attachment: signature.asc
Description: Digital signature