On 19/02/10 10:36, Romain Quey wrote:
Hello Christophe,
Thanks for your quick and detailed answer.
I'm glad to hear this is not due to a memory leak.
As for colors, I want to use the full RGB color palette. Actually,
this is kind of a post-processing, where the color is related to the
value of a given physical variable - I want to visualize the field of
this variable on the mesh.
I understand. For this you should simply use the post-processing module :-)
To visualize fields that are constant per element, the easiest is to
create a .msh file with an "$ElementData" field.
Here's a simple example with a mesh containing 2 elements (2 quads, with
ids 1000 and 1001), with a scalar field equal to 1.05 on element 1000
and 3.141592 on element 1001:
$MeshFormat
2.1 0 8
$EndMeshFormat
$Nodes
6
1 0.0 0.0 0.0
2 0.1 0.0 0.0
3 0.1 0.3 0.0
4 0.0 0.3 0.0
5 0.0 0.15 0.0
6 0.1 0.15 0.0
$EndNodes
$Elements
2
1000 3 2 6 100 1 2 6 5
1001 3 2 6 100 5 6 3 4
$EndElements
$ElementData
1
"Scalar per element"
1
0.0
3
0
1
2
1000 1.05
1001 3.141592
$EndElementData
You can then play with many options (Tools->Options->View[0]) to display
the data.
Romain
On 02/19/10 10:06, Christophe Geuzaine wrote:
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
[email protected]
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
_______________________________________________
gmsh mailing list
[email protected]
http://www.geuz.org/mailman/listinfo/gmsh
