[Gmsh] Mesh with many volumes - memory problem

Christophe Geuzaine cgeuzaine at ulg.ac.be
Fri Feb 19 10:06:41 CET 2010


On 18/02/10 20:51, Romain Quey wrote:
> Hi Gmsh developers, hi everyone,
>

Hello Romain,

> I'm generating meshes with a lot of element sets (or "volumes");
> actually, one element set for each element. It turns out that Gmsh
> uses much more memory than when there is only one element set (for the
> same mesh). Attached are examples of the same mesh made of 8807
> elements, but with 1 or 8807 element sets. The memory needs for
> loading the meshes are:
> - for 1 elset : 35Mb RAM (leak 5Mb, non-leak 30Mb)
> - for 1 elset/elt: 122Mb RAM (leak 92Mb, non-leak 30Mb)
>
> As indicated above, the memory leak reported is much higher when there
> are a lot of element sets (report by valgrind).
 >
 > With a mesh made of 157352 elements, the difference becomes very high:
 > - 1 elset : 84Mb RAM
 > - 1 elset/elt: 1600Mb RAM
 >
 > Of course, this is annoying, and I think it is due to a memory leak in
 > Gmsh.

* With respect to memory leaks:

There might be some very small memory leaks in Gmsh, but the numbers you 
report are probably not actual memory leaks. By default we do not delete 
(free) the memory associated with the loaded models when you exit Gmsh: 
there is no need to do this, as the OS will reclaim all the memory for 
you automatically when the program quits. Freeing everything explicitly 
would make exiting Gmsh much slower, with no added benefit. To detect 
real memory leaks, you need to perform several cycles (say load a mesh, 
delete it, load it again, etc.) and see if the actual memory usage goes 
up. It shouldn't.

This being said, you can free most of the memory by hand if you want by 
adding "Delete All;" at the end of your script. This will not free 
everything, as we always keep one empty model as well as some global 
data in memory, but it will explicitly free most of it.

* With respect to "element sets"

What you call element sets are much more than that: they are actual 
geometrical entities ("volumes"), with associated topology and geometry 
(and many other options, like colors).

Such a geometrical entity has a much larger memory footprint than a mesh 
element: that's completely normal, and by design.

>
> By the way, I'm generating such meshes with one element set for each
> element because I want to assign one particular color to every element,
> which is done through: "Color{R,G,B}{Volume{...};}" for each element.
> Is there a simpler way?

How many different colors do you need? There is no way to assign one 
color per element (for performance/memory reasons: cf. above), but an 
intermediate solution could be to

* define a single volume

* but define several mesh partitions (cf. the additional element tags in 
the .msh format)

You cannot explicitly assign colors to partitions, but partitions can be 
colored using the 20 colors of the "color carousel" (Mesh.Color.Zero, 
Mesh.Color.One, etc.)

Hope this helps,

Christophe




>
> Thanks for your great software,
>
> Romain
>
>
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh


-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine