[Gmsh] Consommation mémoire de Gmsh

[Christophe Geuzaine]

Jean-Francois Remacle wrote:
> 
> Le 27-avr.-09 à 15:13, Franck.LEDOUX at CEA.FR 
> <mailto: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
>>

PS: + 3 doubles to store the coordinates



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