=======Commit 2014-06-05=======
=====Contexte=====
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.
{{ :commit:futur:cpudistribution0.png |}}
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.
{{ :commit:futur:cpudistribution1.png |}}
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.
=====Affichage des boundingBoxes géométriques et de contact dans VizWin=====
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//.
* Premièrement, les boites géométriques, c’est-à-dire les boîtes relatives aux objets de type géométrique sans tenir compte d’aucune profondeur de détection du contact.
* Ensuite, les boites relatives aux interactions de contact. Les dimensions des boites affichées sont dans ce cas étendues par la profondeur de détection du contact correspondante au matériau de contact associé.
=====Comment afficher les boundingBoxes ?=====
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.
{{ :commit:futur:showhidebwin.png |}}
Enfin, dans l’onglet General, il faut cocher la case ''boundingBox'' sous ''Geometry'' et/ou ''contact BoundingBox'' sous ''Global Options''.
{{ :commit:futur:generalbwin.png |}}
=====Signification du code de couleurs des boîtes=====
Les boîtes portent des couleurs spécifiques à la nature de l’objet auquel elles se rapportent.
|< 100% 20em - - - >|
^ Objet géométrique ^ Couleur de boite ^
| Skin | rouge |
| Side | beige|
| Surface | bleu |
| Wire | vert |
| Courbe | violet|
=====Quelques exemples et remarques=====
====Cas-test U6SymRmm====
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.
{{url>//www.youtube.com/embed/rLnsggS3e34?rel=0 noborder allowfullscreen}}
====Cas-test apps.bImp.laursenContact3D====
(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.
{{url>//www.youtube.com/embed/ZczK2mxrARo?rel=0 noborder allowfullscreen}}
====Cas-test apps.bImp.laursenContact2D ====
(auto-contact + contact rigide-défo)
{{url>//www.youtube.com/embed/u83QH8CVYIA?rel=0 noborder allowfullscreen}}
====Cas-test apps.bImp.cylPlast====
(contact défo-défo)
{{url>//www.youtube.com/embed/fU7v97hgPpY?rel=0 noborder allowfullscreen}}
====Cas-test apps.complex.tombeBordEas2D_1====
(contact rigide-défo)
{{url>//www.youtube.com/embed/nOB2hakEAiM?rel=0 noborder allowfullscreen}}
====Cas-test apps.qs.contactCoonsTri====
(contact rigide-défo)
{{url>//www.youtube.com/embed/N_5212sWAFw?rel=0 noborder allowfullscreen}}
Des boîtes de contact relatives à des sides peuvent être observées. En revanche, nous n’avons aucune boîte géométrique …
=====Quelques modifications mineures=====
* La classe ''SkinSet'' est désormais aussi ‘drawable’.
* Le bouton ''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.
* Dans ''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 :
* L’objet ''boundingBox'' et la méthode ''getBoundingbox()'' sont ajoutés les classes ''mtGeoSkin'' et ''mtGeoWire''.
* La méthode virtuelle ''getBoundingBox()'' est ajoutée dans la classe ''mtGeoGObjet''.
* Les outils de contact utilisés dans les 4 classes d’interaction de contact rigide-défo, rigide-défo piloté en forces, défo-défo et auto-contact sont à présent des attributs de classe, tel que déjà réalisé dans la classe mère ''ContactInteraction''.
* Dans la classe ''Element'', j’ai ajouté la possibilité de récupérer les sides et les curves de l’élément.
* Luc a ajouté un print de code d'erreur dans la fonction ''setDir(wdir)'' dans ''toolbox/utilities.py''.
=====Cas-tests de la batterie=====
* Petite correction du chemin de répertoire de travail dans le cas-test ''mtFrequencyAnalysis/tests/frequenciesBeam3D.py''
==== Fichiers ajoutés/supprimés ====
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
--- //[[Y.Crutzen@ulg.ac.be|Yanick Crutzen]] 2014/06/05 //