January 26, 2004

• Modification de FixationSet pour changer un int en UserNo (voir plus bas l'introduction de la classe "numéro utilisateur".

Résumé des modifs:

• Modification de la Géométrie: but = alléger les géométries locales d'éléments et allourdir la géométrie principale (pour une création rapide d'éléments en ALE)
  • Suppression de la classe Topology : cette classe est inutile: en effet, elle définissait la géométrie du maillage qui peut être manipulée exactement comme une géométrie utilisateur. Sa seule raison d'être est de définir un objet distinct pour pouvoir cohabiter à côté d'un objet Geometry dans une liste de propriétés PhySet. J'ai donc résolu le problème en passant un identificateur PhySet (GEOMETRY_PO ou TOPOLOGY_PO) dans le constructeur de Geometry. Ainsi deux objets de cette classes peuvent exister sans conflit. Les fonctions de Topology ont été "remontées" dans Geometry.
  • Création d'une classe LocalGeometry qui ne contient pas la dimension (ni mes futures extensions pour l'ALE). En gros, chaque élement possède une LocalGeometry et le Domain possède deux objets Geometry (la géométrie maillage et la géométrie utilisateur).
  • Création d'une classe UserNo pour gérer les numéros utilisateur (très grosse modifs: beaucoup de classes sont modifiées). Le but est de m'aider dans l'ALE où je manipule des numéros de toutes sortes (internes et utilisateurs) et que je mixe tout. Jetez un oeil à l'implémentation. Cette classe est en fait un int caché dans une classe. Ceux qui ont suivi mon cours connaissent les avantages. Pour rappel:
    • typage fort : pas possible de convertir implicitement un UserNo en int, ni l'inverse
    • possibilité de distinguer des fonctions membres du type
      • getObject(const UserNo &no); (récupération via numéro utilisateur)
      • getObject(const int &no); (récupération via numéro interne)
    • impossibilité de faire de l'arithmétique de numéro sans caster celui-ci explicitement en int (on repère donc très vite les endroits critiques).
    • clarté du code obtenu
    • possibilité de créer un objet invalide (statique) UserNo()::invalid() qui remplace avantageusement les "magic numbers" -1 ou 0. Bref, au lieu de faire if(no==-1) error(); il faut faire if(no.isInvalid()) error();
  • Suppression de la dérivation NumberedObject<T> des GeoObjects<T>. En clair, ca veut dire, par exemple, que une Curve n'est plus un PointSet, une Skin n'est plus un SideSet, etc. J'ai remplacé cette dérivation par de la composition (dérivation=être, composition=avoir). Bref, une Curve a un PointSet et une Skin possède un SideSet. L'avantage est double: on allège la hiérarchie de classe et on peut restreindre les opérations que l'utilisateur peut faire sur une courbe (c'est par exemple débile de pouvoir faire un set_step() ou un build_hash() localement au niveau de la courbe).
  • Séparation de la partie géométrique de NumberedObject en une classe dérivée GObject. Cette nouvelle classe devient la classe de base des objets géométriques. La conséquence directe est que les NumberedObjects qui ne sont pas géométriques (les interactions, les courbes de Luc, etc) n'ont plus une interface géométrique bidon comme c'était le cas avant.
  • Modification des NumberedObjectSets et dérivés: but=séparer ce qui est générique de ce qui est géométrique. C'est la suite du point précédent, transposé au niveau des sets. Les classes suivantes ont été placées dans le kernel: NumberedObject, NumberedObjectSetBase, NumberedObjectSetTemplate. Bien sûr, c'est pas immédiat. Le plus gros problème est de gérer les sets avec table de hashage parce qu'ils sont mal placés dans la dérivation. Auparavent, un HashedNumeberedObjectSet possède des fonctions géométriques. Si on découpe NumberedObjectSetTemplate en deux classes et qu'on intercale ensuite la gestion de la table de hashage (la classe de base doit pouvoir être hashée), on va être obligé de gérer tous les objets géométriques par table de hashage (coûteux en mémoire). J'ai donc découplé l'implémentation de l'interface avec le design pattern "Bridge". La partie "gestion des composants" (hashés ou pas) est codée dans une classe dérivée de SetImplementor (soit VectorSetImplementor ou HashsetImplementor). La gestion des données est donc complètement déléguée à ces classes et l'aspect géométrique peut être découplé facilement.
  • Nettoyage des I_ de la géométrie:
    • modifications pour refléter le changement de structure.
    • suppression des fonctions print() et size() qui sont déjà définies dans I_PhySet.
    • ajout du namespace mtGeo:: où ça manquait
  • Création d'une classe GObjectSetTemplate: elle contient la partie géometrique de l'ancienne interface de NumberedObjectSetTemplate.
  • NumberedObject dérive maintenant de PhySet: cette modifs permet de simplifier tous les appels PhySet (get_name() par exemple). De plus, les objets GeoObjects ne sont plus des FastPhySet (c'était inutile). On ne gagne cependant pas de la mémoire sur cette opération puisqu'ils contiennent maintenant un FastPhySet.
• Mailleurs: ajout d'une géométrie cible qui va contenir le maillage.
• ALE: nouveaux développements dans AuxiliaryMeshBuilder2. Mon but est de créer le maillage auxiliaire de volumes finis en ALE en "maillant" directement chaque élément (avec les mailleurs de géométrie). Pour l'instant, c'est la classe AuxiliaryMeshBuilder qui se charge de diviser chaque élément de manière un peu dégueu en faisant beaucoup d'hypothèses (1 seul type d'élément par exemple). Je fais de l'arithmétique avec les numéros (honte sur moi) et grâce à ce commit, les endroits où je bidouille sont identifiables facilement. Pour l'instant, la classe AuxiliaryMeshBuilder fonctionne (elle crée un maillage) mais elle est très lente parce que les mailleurs travaillent sur les numéros utilisateurs et utilisent la fonction getLargestNo() (très lente). Mon idée est de mettre en cache les valeurs envoyées par getLargestNo() dans la classe Geometry. Cette cache s'appelle IndexGenerator et est déjà commitée. Vu que je voulais pas mettre un IndexGenerator par élément (chaque élément possède une géométrie), j'ai splitté la géométrie en 2 classe (voir plus haut).

De manière plus visuelle, vous pouvez voir les changements de hiérarchie via des petits dessins à moi:

• Transformation au niveau des classes Topology et Geometry.
• Transformations au niveau des classes géométriques (avant - après).

Pour mettre à jour:

• virez tout ce que vous avez dans oo_kernel oo_kernel/i_ oo_geo oo_geo/i_ et ajoutez à nouveau tous les fichiers de ces répertoires après update.

	created :January 22, 2004		modified : January 26, 2004
	contact : r_boman_AT_yahoo.fr