Dans le but de réduire le temps de calcul des simulations lagrangiennes de profilage, Romain a un jour soumis l’idée de faire de la gestion dynamique d’interactions de contact. Bien que Metafor dispose d’un algorithme de boîtes permettant d’éviter de coûteuses recherches de projections, le temps passé dans les routines de détection du contact serait ainsi réduit en amont de l’algorithme de boundingBox en lui-même.
Sans aucune gestion dynamique des interactions de contact, la répartition du temps CPU pour un grand modèle lagrangien de profilage (cf. diagramme ci-dessous) montre que 46% du temps est consacré aux seules routines de détection du contact.
Suite à la gestion dynamique des interactions implémentée dans le modèle de profilage lors du commit 1897, il a été constaté, que le temps de calcul a chuté de manière significative. Le wall clock time global a en effet été réduit de 61% pour le même modèle de profilage. De plus, en comparant les diagrammes de répartition du temps CPU entre les 2 modes de gestion des interactions de contact, on peut remarquer que le gain n’était pas seulement restreint aux seules routines de détection du contact. L’assemblage des forces internes, externes, d’inertie et de la matrice de raideur tangente bénéficiait également de cette gestion dynamique des interactions de contact.
Toutefois, ce gain en temps CPU n’était pas vraiment attendu tant sur les routines autres que la détection du contact que sur son amplitude. Ce constat a dès lors soulevé quelques interrogations. Par la gestion dynamique des interactions de contact, il était attendu que les routines de détection du contact soient sollicitées dans une moindre mesure en épargnant l’algorithme de boundingBoxes et de fait le double temps d’accès dans la base de données pour chaque élément de contact (qui s’élève à l’ordre d’1 million d’éléments pour ce grand modèle de profilage). Cependant, de par la nature des boites alignées selon les axes globaux, l’algorithme de boundingBox réalise des opérations simples et peu coûteuses et ne peut a priori pas être seul responsable de ce large gain en temps CPU (46% → 13%). Une analyse de profilage du code Metafor sur de petits ces-tests de profilage révèle en effet que le temps passé dans le test de boundingBox n’est pas dominant. Une autre piste est que les boîtes soient de dimensions excessivement grandes, entraînant de coûteuses recherches de projection du nœud des éléments de contact sur chaque outil maître.
L’affichage des BoundingBoxes dans la fenêtre VizWin de Metafor est motivé par les larges écarts de performances décrits ci-dessus au niveau des routines de détection du contact pour lesquelles les raisons ne peuvent être clairement cernées. Cet affichage des boundingBoxes est par ailleurs profitable à tout utilisateur de Metafor pour la plus grande compréhension des routines de détection du contact.
Deux types de boîtes sont à distinguer pour leur affichage dans VizWin.
Dans l’onglet ShowHide de Bwin, il est nécessaire de choisir les objets 'drawables' soit par glisser-déposer à partir de l’objectBrowser, soit en décommentant les lignes de code dans la fonction vizu()
du fichier utilities.py présent dans oo_meta/toolbox
.
Il est possible de contrôler l’affichage des boundingBoxes géométriques en choisissant les objets géométriques tel que skinDrawable
, surfaceDrawable
, wireDrawable
, curveDrawable
… ou encore l’interactionDrawable
(pour du contact défo-défo).
Une seconde possibilité est l’affichage des boundingBoxes de contact en choisissant les interactions de contact.
Enfin, dans l’onglet General, il faut cocher la case boundingBox
sous Geometry
et/ou contact BoundingBox
sous Global Options
.
Les boîtes portent des couleurs spécifiques à la nature de l’objet auquel elles se rapportent.
Objet géométrique | Couleur de boite |
---|---|
Skin | rouge |
Side | beige |
Surface | bleu |
Wire | vert |
Courbe | violet |
Dans le cas particulier des simulations de profilage, deux remarques peuvent être formulées en ce qui concerne les boundingBoxes. Tout d’abord, les boîtes ne présentent pas des dimensions excessives comme on aurait pu le penser au vu de la différence de performances expliquées ci-dessus. Ensuite, nous pouvons remarquer étonnement que seules les boîtes relatives aux objets géométriques de type courbe sont affichées. Bien que implémentées dans Metafor, les boites relatives aux objets de type contour, surface de révolution et skin ne sont pas utilisées. Une raison potentielle de l’écart de performances dans les routines de détection du contact entre les 2 modes de gestion des interactions, est donc sous nos yeux. Il est en effet possible de rejeter le nœud de nombreux éléments de contact bien en amont dans les routines de détection en (re ?)mettant en place un système hiérarchique de boundingBoxes. On s’affranchit ainsi de nombreuses et coûteuses opérations de projection dans le plan défini par l’axe de la surface de révolution et le contour la définissant.
(auto-contact + contact rigide-défo)
Nous pouvons observer quelques boîtes clignotantes au niveau des interactions de contact rigide-défo, laissant penser à quelques resets de boites réalisés trop fréquemment.
Il est important de noter qu’une boundingBox n’est pas affichée dans VizWin si son flag needToBeComputed
vaut true
. Seules les boîtes pour lesquelles Metafor fait appel à la méthode insideTest()
de la classe BoundingBox
(si la boundingBox peut être définie et si la profondeur de détection du contact est positive) sont donc affichées.
(auto-contact + contact rigide-défo)
(contact défo-défo)
(contact rigide-défo)
(contact rigide-défo)
Des boîtes de contact relatives à des sides peuvent être observées. En revanche, nous n’avons aucune boîte géométrique …
SkinSet
est désormais aussi ‘drawable’. Sides
dans le menu General de BWin
est ajouté pour permettre l’affichage des boundingBoxs relatives aux skins
, skinset
, sides
et sideset
sans l’affichage simultané de l’objet en lui-même. Il est à noter que l’affichage des sides est responsable de plantages de Metafor, si la side est une surface de révolution.oo_meta/toolbox/utilities.py
, j’ai ajouté en commentaires diverses possibilités pour générer des drawables (wireSet
, sideSet
, sides
, skinSet
, skins
, elementSet
de chaque interaction, les éléments d’elementSet
de chaque interaction).Les modifications dans la partie « calcul » de Metafor, que j’ai limité autant que possible pour ce commit :
boundingBox
et la méthode getBoundingbox()
sont ajoutés les classes mtGeoSkin
et mtGeoWire
.getBoundingBox()
est ajoutée dans la classe mtGeoGObjet
.ContactInteraction
. Element
, j’ai ajouté la possibilité de récupérer les sides et les curves de l’élément.setDir(wdir)
dans toolbox/utilities.py
.mtFrequencyAnalysis/tests/frequenciesBeam3D.py
A oo_meta\mtDrawables\BBox.cpp A oo_meta\mtDrawables\BBox.h A oo_meta\mtDrawables\ContactInteractionCloud.cpp A oo_meta\mtDrawables\ContactInteractionCloud.h A oo_meta\mtDrawables\DdContactInteractionDrawable.cpp A oo_meta\mtDrawables\DdContactInteractionDrawable.h A oo_meta\mtDrawables\FdRdContactInteractionDrawable.cpp A oo_meta\mtDrawables\FdRdContactInteractionDrawable.h A oo_meta\mtDrawables\RdContactInteractionDrawable.cpp A oo_meta\mtDrawables\RdContactInteractionDrawable.h A oo_meta\mtDrawables\ScContactInteractionDrawable.cpp A oo_meta\mtDrawables\ScContactInteractionDrawable.h A oo_meta\mtDrawables\SkinDrawable.cpp A oo_meta\mtDrawables\SkinDrawable.h A oo_meta\mtDrawables\SkinSetDrawable.cpp A oo_meta\mtDrawables\SkinSetDrawable.h A oo_meta\mtDrawables\WithBBox.cpp A oo_meta\mtDrawables\WithBBox.h A oo_meta\mtDrawables\WithSide.h
— Yanick Crutzen 2014/06/05