• Suppression du mécanisme “SearchIndex”

• Mecanisme “SearchIndex”
  • Le mécanisme “SearchIndex” consistait en l'ajout d'un entier (dénommé searchIndex) dans tout NumberedObject.
  • Un algorithme en 2 étapes permettait de parcourir tous les éléments géométriques (généralement des points) d'un objet de manière unique. La procédure consistait en
    • La mise à 0 des searchIndex de tous les sous objets (InitMeshPointSearch, InitNodeSearch, …)
    • Le parcours des entitiés à l'aide d'un while

    goSlave->InitMeshPointSearch
    while(node = goSlave->getNextMeshPoint()) 
    {
         ...
    }

• Avantages :
  • Ca marche (bien que parfois, c'est par chance)
  • Ca n'a pas l'air trop lent
  • Le même objet sera toujours parcourus de la même manière (dépendant de la hiérarchie des objets géométriques)
• Problèmes :
  • Pas de boucles imbriquées (j'en ai trouvé …) meme dans des sous routine (pas toujours évident à repérer)
  • Complexité schéma en 2 étapes (on effectue 2 fois la recherche à travers les objets géométriques)
  • Pas parallélisable
  • memoire on alloue un entier dans presque tous les objets
  • Nombre de fonctions de gestion du SearchIndex
  • Objet non const (le parcours des objets modifiant la valeur de searchIndex)
  • …
• Méthode de remplacement
  • Schéma en 2 étapes :
    • Remplissage d'un set de pointeurs sur l'objet recherché
    • parcours du set
  • Avantages :
    • le set étant un conteneur de type 'UniqueAssociativeContainer' (1 seule occurence de chaque objet), la gestion des objets uniques est directe
    • le set peut être Hashé pour accélérer la détection des doublons (utilisation des hash_set extension de la STL)
    • il est totalement permis d'imbriquer des boucles
    • beaucoup d'objets/fonctions peuvent devenir const
    • gestion par la stl (en principe optimisé)
  • Désavantages :
    • Les hash_set ne permettent pas un parcours des objets dans un ordre particuliers (dépend de la manière dont la table est hashée)
    • les set simples (triés sur base des pointeurs) ne vont assurer que le parcours dans l'ordre croissant des pointeurs
  • OR :
    • dans le cas du restart il est important que les éléments soient créés dans le même ordre pour que la relecture du fac ait un sens (seul les éléments de contact sont affectés. Auparavant c'est grace à la systématicité du balayage des objets que ca fonctionnait)

⇒ pas de hash_set dans la création des éléments de contact (ContactInteraction::execute())

• En cours de restart, la mémoire étant fractionnée différement (par les opérations préliminaires) les pointeurs vers les MeshPoints ne sont pas les mêmes … ⇒ pas de set simples triés sur base des pointeurs
• ⇒ mise en place de set (moins performant mais bon) sur les numero d'objets
• Utilisés aussi pour les extracteurs / fonctions objectives (ca foutait un peu la m…e dans l'opti)

• Ces dernière remarques posent la question de la gestion de la numérotation des objets dans le cadre du restart, du remaillage, de la parallélisation

• Move2
• Utilisation de hash_set pour déplacer la géométrie (cf test Enim)

• up to date

• Unifier les remplissage de set, hash_set,… / sur le pointeur, numéro, …

(peut être par génération d'une classe mère dont dériverait les divers conteneurs quid des perfs)

• Test / Remplacement des hash de Romain par ceux de la STL dans les GObjectSet

• remplacer les fillNumberedObjectHashSet(pointsNObjects,POINT_ID) (ex :getNextNumberedObject(POINT_ID))) par fillPointHashSet(pointsNObjects)

• Ajout de const (où c'est possible)

• Utiliser en conjonction avec les operateurs de transformation géométrique dans les Loadings

A mtGeoStdHashSet.h/cpp
R

— Luc PAPELEUX 2008/04/29