===== Commit-2008-04-29 ===== * Suppression du mécanisme "SearchIndex" ===== Modifs ===== * ** 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) ===== Tests ===== * ===== Projet ===== * up to date ===== ToDo list ===== * 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'' ===== Fichiers ajoutés/supprimés ===== A mtGeoStdHashSet.h/cpp R --- //[[L.Papeleux@ulg.ac.be|Luc PAPELEUX]] 2008/04/29 //