===== Commit 2016-11-14 ======

Ce commit est pour corriger un bug lors de la visualisation des outils de contact et territoire de contact en 3D, ainsi que l'ajout d'une surface de révolution ouverte. 

==== Visualisation des outils de contact et territoire de contact en 3D ====

Lors l'on visualisait les outils en 3D et leurs normales, on constatait la présence de plus de deux normales sur la frontière entre deux surfaces par exemple, ce qui semblait pas naturel du tout. J'ai corrigé ce bug pour ne visualiser que des entités géométriques du type 3D lors d'une modélisation 3D, sinon on visualisait des entités géométriques du type 2D et type 3D lors d'une modélisation 3D. Informatiquement parlant, il faut qu'un des deux objets ContactTool3DCloud ou ContactTool2DCloud soit effectivement remplis en 2D et en 3D. 

==== Surface de révolution ouverte ====

En développant le cas test de la square box et de la cross box, nous avons constaté une discontinuité de la normale sur la frontière entre les différentes sous-surfaces définissant les outils de contact (celles définies par 4 arcs de cercle). En investiguant un peu, ce type de discontinuité est tout à fait normal, si on utilise des patchs de Coons bilinéaires. Par définition, ces derniers garantissent une continuité C0 entre eux et non une continuité C1 (continuité de la normale). Pour retrouver une continuité du type C1, il faut utiliser des patchs de Coons bicubiques mais ce dernier nécessite l'ajout de termes non triviaux sur les sommets du patch (les dérivés croisées = twist) en plus des tangentes sur les frontières du Patch qui correspondent aux tangentes des courbes définissant le Patch. 

Pour résoudre ce problème, soit on devait utiliser des outils du type MultiProjSkin(), ce qui alourdit le traitement des projections sans gain réel, soit on choisit une surface alternative pour représenter la surface passant par 4 arcs de cercle qui est ici une surface de révolution ouverte.

Finalement, le cas test fonctionne jusqu'au bout car cette discontinuité est localisée en certains endroits, mais cette discontinuité peut ralentir la convergence des itérations mécaniques, voir stopper le calcul en fonction des paramètres du contact !
<code>
  openrevsur = surfaceset.add( OpenRevolutionSurface(number, axe, wire, angle) )

with
| ''number'' | User number (unique among surfaces and $\ge 1$) |
| ''axe''                    | ''[[courbes|Line]]'' which defines the revolution axis | 
| ''wire''                   | ''[[contours|Wire]]'' which will rotate along the revolution axis (it cannot intersect the axis on its first point and must be coplanar with it). | 
| ''angle'' | Opening angle $]0, 2 \pi[$ |
</code>

Du point de vue code source, j'ai opté pour une dérivation des classes correspondantes au opérateur de projection et à la surface géométrique. Nous évitons ainsi des copier/coller entre les deux objets fort similaires, mais il y a l'une ou l'autre modifications à considérer, lorsque la surface de révolution est ouverte. Finalement, cela permet aussi une plus grand flexibilité si on désire combiner ce type de surface avec d'autres objects "Metafor".

===== Fichiers ajoutés/supprimés ======

<code>
[a]:mtGeo\mtGeoOpenRevolutionSurface.cpp  
[a]:mtGeo\mtGeoOpenRevolutionSurface.h 
[a]:mtGeo\mtGeoOpenRevolutionSurfaceProjectionOperator.cpp  
[a]:mtGeo\mtGeoOpenRevolutionSurfaceProjectionOperator.h  
[a]:mtGeo\mtGeoOpenRevolutionSurfaceProjectionOperator.inl
[r]:
</code>

===== Cas tests ajoutés/supprimés ======

<code>
[a]:mtContact\tests\squeezeTestOpenRevSurfStiffAna.py
[a]:mtContact\tests\squeezeTestOpenRevSurfStiffNum.py
[r]:
</code>

 --- //[[gwautelet@ulg.ac.be|gaëtan]] 2016/11/14 11:01//