Differences

This shows you the differences between two versions of the page.

--- commit:2014:06_05 [2014/06/05 10:38] – crutzen
+++ commit:2014:06_05 [2024/03/01 15:54] (current) – boman
@@ Line 13: / Line 13: @@
 {{ :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 boundingBoxs 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.
+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 boundingBoxs géométriques et de contact dans VizWin=====
+=====Affichage des boundingBoxes géométriques et de contact dans VizWin=====
-L’affichage des BoundingBoxs 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 boundingBoxs est par ailleurs profitable à tout utilisateur de Metafor pour la plus grande compréhension des routines de détection du contact.
+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//.
@@ Line 25: / Line 25: @@
   * 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 boundingBoxs ?=====
+=====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 boundingBoxs 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).
+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 boundingBoxs de contact en choisissant les interactions de contact.
+Une seconde possibilité est l’affichage des boundingBoxes de contact en choisissant les interactions de contact.
 {{ :commit:futur:showhidebwin.png |}}
@@ Line 52: / Line 52: @@
 =====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 boundingBoxs. 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 boundingBoxs. 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.
+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.
+<WRAP centeralign column 100%>
+{{url>//www.youtube.com/embed/rLnsggS3e34?rel=0 noborder allowfullscreen}}
+</WRAP>
 ====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.
+<WRAP centeralign column 100%>
+{{url>//www.youtube.com/embed/ZczK2mxrARo?rel=0 noborder allowfullscreen}}
+</WRAP>
 ====Cas-test apps.bImp.laursenContact2D ====
 (auto-contact + contact rigide-défo)
-<html>
+<WRAP centeralign column 100%>
-<iframe width="640" height="360" src="//www.youtube.com/embed/u83QH8CVYIA?rel=0" frameborder="0" allowfullscreen></iframe>
+{{url>//www.youtube.com/embed/u83QH8CVYIA?rel=0 noborder allowfullscreen}}
-</html>
+</WRAP>
 ====Cas-test apps.bImp.cylPlast====
 (contact défo-défo)
+<WRAP centeralign column 100%>
+{{url>//www.youtube.com/embed/fU7v97hgPpY?rel=0 noborder allowfullscreen}}
+</WRAP>
 ====Cas-test apps.complex.tombeBordEas2D_1====
 (contact rigide-défo)
-<html>
+<WRAP centeralign column 100%>
-<iframe width="853" height="480" src="//www.youtube.com/embed/nOB2hakEAiM?rel=0" frameborder="0" allowfullscreen></iframe>
+{{url>//www.youtube.com/embed/nOB2hakEAiM?rel=0 noborder allowfullscreen}}
-</html>
+</WRAP>
 ====Cas-test apps.qs.contactCoonsTri====
 (contact rigide-défo)
-<html>
+<WRAP centeralign column 100%>
-<iframe width="640" height="360" src="//www.youtube.com/embed/N_5212sWAFw?rel=0" frameborder="0" allowfullscreen></iframe>
+{{url>//www.youtube.com/embed/N_5212sWAFw?rel=0 noborder allowfullscreen}}
-</html>
+</WRAP>
 Des boîtes de contact relatives à des sides peuvent être observées. En revanche, nous n’avons aucune boîte géométrique …
@@ Line 95: / Line 116: @@
   * 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''.
+  * Luc a ajouté un print de code d'erreur dans la fonction ''setDir(wdir)'' dans ''toolbox/utilities.py''.
 =====Cas-tests de la batterie=====
@@ Line 103: / Line 124: @@
 ==== Fichiers ajoutés/supprimés ====
 <code>
+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
 </code>
  --- //[[Y.Crutzen@ulg.ac.be|Yanick Crutzen]] 2014/06/05 //