Ce commit est pour l'amélioration de la lisibilité du choix du type de projection en contact en 2D.

Il est possible de générer aisément une géométrie maillée de type Tore à l'aide du mailleur de révolution de Metafor. Il suffit de faire tourner autour d'un axe de révolution une section droite du type anneau.

Pour imposer les conditions aux limites sur la surface interne ou surface externe du Tore, j'ai ajouté le sélecteur suivant :

group.addMeshPoints(TorrusSelector(Axe(curveset(1)), Cx, Cy, Cz, rMin, rMax))

gets all nodes in the toroidal sector defined by the revolution axis Axe(curveset(1)), the annular cross section centroid is (Cx, Cy, Cz) (This is the cross section used in the revolution mesher.) and the minimal and maximal radii rMin and rMax.

J'ai éliminé un problème de Memory Leak suite à une utilisation du mécanisme IncRef/DecRef dans les objets de la visualisation.

Pour information, ce mécanisme n'est pas multi-thread. Dès lors, nous avons décidé de conserver une trace de tous les objets Metafor (on fait un incRef avant de le stocker dans un std::vector) que l'on demande de visualiser dans l'interface Graphique dans l'objet VizWin (Thread Python) via la fonction add(WithDrawable *) de VizWin. Une fois, que l'objet Metafor est passée dans le VizWinWidget (Thread Visu) par signal, il n'y a plus lieu de faire les incRef et decRef dans ce thread. Finalement, lors de la destruction de l'objet VizWin, on effectue un decRef de tous les objets stockés dans ce std::vector).

La routine pour la décision du type de projection de contact reste l'une des plus imbuvables et nébuleuses du code source Metafor.

L'idée fondamentale de cet objet est de choisir parmi toutes les projections admissibles d'un point sur un MultiProjWire celle qui correspond le mieux à la situation rencontrée. Intuitivement, on pourrait choisir celle de distance minimale mais nous devons traiter proprement les problèmes de coins (partie concave - aucune projection et partie convexe - double projection) pour assurer une continuité de la normale localement au voisinage du coin. Attention, que lors de la projection du point sur chaque segment du MultiProjWire, on doit étendre ces segments (u in [0, 1] devient u in [-0.1 1.1]), sinon on ne peut pas traiter les coins concaves proprement !

A cause de l'approche itérative utilisée actuellement (On prend une projection de départ et on boucle sur toutes projections !), il était possible de partir de 10 projections admissibles et d'avoir au final aucune projection !!!! Dans le même ordre d'idée, il est très difficile de suivre les décisions prises par l'algorithme pour le type final de la projection.

Au lieu de cette approche itérative, j'ai préféré une approche sous forme de filtre (On élimine au fur et à mesure les projections pour effectuer un choix sur un nombre restreint de projections). De cette manière, nous pouvons facilement suivre l'algorithme de décision puisqu'il est possible d'afficher les projections retenues au fur et à mesure que l'on avance dans la décision. Dans le même ordre d'idée, il est également aussi aisé d'ajouter un nouveau type de projection ou nouveau cas pathologique à traiter dans ce type de structure sous forme de filtre.

Finalement, pour le traitement des projections multiples en 3D, il manque des configurations possibles de projection dite “multiple” pour les projections situées au voisinage des nœuds. Notamment, c'est une erreur fondamentale de considérer les traitements des cas 3D et 2D de la même manière pour ce cas de figure dans le but de rendre continue la normale en cet endroit (c'est-à-dire choisir une de deux directions principales de courbure locale), pour la bonne et simple raison que nous avons en 3D deux courbures principales ce qui donne lieu localement à soit un point de selle, ou un sommet concave ou un sommet convexe. Je vais continuer de scinder le 2D et le 3D et tenter d'ajouter les cas cités précédemment comme nouveau type de projection uniquement en 3D.

J'ai ajouté des cas tests du type contact défo-défo ou self contact dans la batterie. Ces cas tests peuvent être utilisées pour regarder la manière dont évolue le temps CPU de la routine de détection de contact en fonction de la finesse du maillage.

[a]:oo_meta\mtGeo\mtGeoWireProjectionSelector.cpp
[a]:oo_meta\mtGeo\mtGeoWireProjectionSelector.h
[a]:oo_meta\mtGeo\mtGeoWireProjectionSelector.inl
[r]:

[a]:oo_meta\mtContact\tests\threeBeamsRingContactTest.py
[a]:oo_meta\mtContact\tests\threePlatesCylinderContactTest.py
[a]:oo_meta\mtContact\tests\threeRingsContactTest.py
[a]:oo_meta\mtContact\tests\torusCylinderContactTest.py
[a]:oo_meta\mtContact\tests\twoRingsContactTest.py
[a]:oo_meta\mtContact\tests\twoToriContactTest.py
[r]:

— gaëtan 2016/08/30 16:00