[Gmsh] Consommation mémoire de Gmsh

Jean-Francois Remacle jean-francois.remacle at uclouvain.be
Mon Apr 27 16:46:34 CEST 2009


Le 27-avr.-09 à 15:13, Franck.LEDOUX at CEA.FR a écrit :

> Bonjour,
>
> Je me permets de vous contacter suite à une étude que j’ai effectuée  
> du code source de Gmsh.
>
> Pour rappel à Jean-François, nous nous sommes croisés à l’IMR l’an  
> passé. Je travaille au CEA sur l’activité maillage (hexaédrique  
> surtout). Dans le cadre de nos travaux actuels, nous développons une  
> structure de données de maillages en C++ à l’aide la programmation  
> générique.  J’ai présenté un « short note » sur cette structure à  
> l’IMR, et je présente un papier plus long à l’ISGG 2009 à Montréal  
> fin mai (suivi d’un papier journal pour la fin d’année avec prise en  
> compte du parallélisme et modèle théorique de maillage générique).
>


je serai aussi a ISGG ;-)

> Pour ce papier, nous avons regardé différentes structures de données  
> dont celle interne à Gmsh (outil que j’ai testé à titre personnel et  
> que j’apprécie beaucoup). Bref, notre étude est purement théorique  
> et concerne l’occupation mémoire potentielle de différentes  
> structures (je vous joins le papier où l’on parle de Gmsh page 11).   
> Au regard du code source, nous somme arrivés à considérer que la  
> structure de données utilisé dans Gmsh était relativement minimale.  
> Pour un cas 3D, seules les mailles (tetra, hexa,…) et les nœuds sont  
> représentés. Les nœuds n’ont aucune connaissance de leur voisinage  
> et les mailles sont simplement définies à partir des nœuds (pour les  
> algos type Delaunay, vous enrichissez votre représentation d’une  
> structure qui décore les mailles en ajoutant la connaissance des  
> mailles voisines).
>
> Au vu des vos différentes classes et du fichier MElement.h (je  
> crois), nous sommes arrivés au calcul suivant pour un maillage  
> tétraédrique en configuration minimale:
>
> Un tetra est défini par
> 1 id (int)
> 1 flag (char)
> 4 pointeurs vers les nœuds
> 1 pointeur vers ce tetra à partir de la GRegion à discrétiser
> 1 pointeur vers une table virtuelle
>
> Un nœud est défini par
> 1 id (int)
> 1 index (int) présent pour raison algorithmique
> 2 chars pour la visibilité et l’ordre du nœud
> 1 pointeur vers une table virtuelle
>
> Si l’on considère que l’on est sur une machine 64bits,  après  
> alignement mémoire, on obtient pour un tetra, 7 x 64bits et pour un  
> nœud 3 x 64bits. Sachant que dans un maillage tetra, il y a environ  
> 5 fois plus de tetras que de nœuds, si n est le nombre de nœuds, on  
> obtient
> 7x 5n + 3n = 38n x 64bits.
>
> Ma question est donc de savoir si nous vous êtes d’accord avec cela.  
> Je voulais vous contacter plus tôt pour cela mais cela m’est  
> complètement sorti de la tête si jamais je me suis trompé, je  
> n’hésiterai pas à rectifier tout cela.
>


Je pense que c'est correct, nonobstant le fait que cette structure est  
incapable de "mailler". Il faut ajouter
les voisins pour cela.

  je serai content d'en reparler a ISGG

JFR

> Merci d’avance pour votre réponse,
>
> Franck Ledoux
>

----------------
Prof. Jean-Francois Remacle
Universite catholique de Louvain (UCL)
Tel : +32-10-472082 -- Mobile : +32-473-909930




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20090427/302e4766/attachment.html>