[Gmsh] Consommation mémoire de Gmsh
Christophe Geuzaine
cgeuzaine at ulg.ac.be
Wed Apr 29 08:38:17 CEST 2009
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