Metafor

BoundingBoxes - suite

• Suite à la parallélisation du contact, le calcul et la mise à jour des bounding-boxes pour le contact suivaient 2 schémas différents selon que l'on était en parallèle (via un pré-calcul explicite) ou pas (avec un flag invalidé en amont et le calcul unique de chaque BBox au besoin)
• au delà de devoir gérer 2 schéma d'intégration selon le parallélisme, chaque méthodes avaient son inconvénient :
  • Le pré-calcul des BBox (pour les calculs parallèles) pouvait amener à calculer plusieurs fois le même outil (si il participait à plusieurs interactions de contact)
  • l'invalidation des BBox et le calcul au besoin nécessiterait un mutex au moment du calcul de la BBox, ce qui n'est pas optimal du tout
• Le choix s'est posé sur un mix des 2 méthodes :
  • les BBox conservent leurs flags de validité (pour ne calculer que 1 seule fois chaque BBox)
  • les BBox sont explicitement invalidées à chaque pas de temps (RDContactInteraction) ou chaque iteration (DDContactInteraction)
  • le calcul des BBox est explicitement appelé hors boucle parallèle (nb : pour les outils facetisés, les boucles sur les facettes pourraient être rendues parallèles) et une seule fois par objet grace au flax de validité
• Dans la mesure des possibilités, chaque objet sur lequel on calcule une bbox conserve celle-ci (quitte à légèrement augmenter la mémoire) et on essaye de ne plus “rediriger” des bbox
• Attention, il reste un soucis sur les QuadSide dont les BBoxes sont calculées sur base des 4 points, et le projectionOperator est le SurfaceOperator générique (d'où la copie de la BBox QuadSide vers la surface sous-jascente)
• Attention2 : les BBoxes sont aussi utilisées dans le remaillage (mais de manière moins claire) à travers les fonctions “insideForConvexe”, “preCompute2BoundingBox”,…
• Attention 3 : l'interaction entre BBox et les méthodes d'arbre WithBoundaryVolume ne me semblent pas nécessairement très claire (⇒ si vous observez un soucis, n'hésitez pas)
• To Be Continued : Un certain nombre d'opérations géométrique m'ont interpellé en tombant dessus et une grosse remise à plat serait bénéfique à la lisibilité du code. Des refactoring à prévoir serait :
  • d'implémenter des opérateurs de projection optimisé pour les faces maillées (QuadSide)
  • supprimer la couche “ProjectionOperator” en créant un “ProjectionData” reprenant les paramètres de projection et en déplacant les fonctions de projection dans les classes géométriques
  • …

• Remeshing :
  • Ajout d'un TestSuiteChecker TSC-STP reprenant le nombre de remaillage

Added :
Deleted : 
M : 

Adding: 
Deleted : 
Moved : 

— Luc Papeleux 2018/03/13