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

[Yves Renard]

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 gna.org/projects/getfem. Thank 
you anyway for this bug report.

Yves.


> 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.

-------------------------------------------------------------------------
  Yves Renard (address@hidden)       tel : (33) 04.72.43.80.11
  Pole de Mathematiques,                       fax : (33) 04.72.43.85.29
  Institut Camille Jordan - CNRS UMR 5208
  INSA de Lyon, Universite de Lyon
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE
  http://math.univ-lyon1.fr/~renard
-------------------------------------------------------------------------