[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Getfem-users] memory leakage somewhere in getfem::mesh_im_level_set

From: Yves Renard
Subject: Re: [Getfem-users] memory leakage somewhere in getfem::mesh_im_level_set
Date: Fri, 6 Jul 2007 13:26:57 +0200
User-agent: KMail/1.9.5

Dear Andriy,

Thank you for your program. The problem was that the release of structures 
fem_precomp and geotrans_precomp attached to your temporary 
getfem::mesh_im_level_set object was not done. This release is normally done 
taking into account some dependances and the dependance between these 
structures and  the integration methods was not declared properly. I made the 
corrections and there is no more memory leakage in your program. It touches a 
lot of files in the library so that i am afraid the simple way for you is to 
dowload the whole library from the svn tree at Thank 
you anyway for this bug report.


> Dear Yves,
>       Here is a simple program that you can use to find a problem with memory
> leakage. Before you compile it, please make sure that your getfem and qhull
> libraries can be linked the way it is indicated in that  tiny Make file the
> program comes with.
>       The program does the following. It repeatedly solves a 2D scalar 
> elliptic
> problem on a unit square with two types of boundary conditions: Dirichlet
> conditions where the solution is set to -0.3 on the top and bottom of the
> square and a zero Dirichlet condition, defined on the boundary of another
> mesh, that overlaps with the unit square mesh. During every increment that
> embedded mesh moves with small steps through a unit mesh and a level set
> function that defines a boundary of this embedded mesh is recalculated with
> class  level_set_from_mesh (you can see the value of this level set
> function by plotting *_level_set_func.vtk). The Dirichlet condition is
> calculated similar to fictitious domain method, with distributed Lagrange
> multiplier, defined on the boundary of this moving embedded mesh. The
> elements of the problem are integrated in a conventional way, except the
> elements that are crossed by the level set are integrated only outside the
> level set (this greatly improves the accuracy of the gradient of the
> solution on the boundary of the embedded structure).
>       Everything calculates fine (see the *_solution_threeD.vtk files) except
> that you can see that the memory of the program after the increment 1 is 
> around 30MB and after the last increment 10 is around 130MB.
> Thank you very much in advance,
>                                                       Andriy


  Yves Renard (address@hidden)       tel : (33)
  Pole de Mathematiques,                       fax : (33)
  Institut Camille Jordan - CNRS UMR 5208
  INSA de Lyon, Universite de Lyon
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE

reply via email to

[Prev in Thread] Current Thread [Next in Thread]