Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2017:08_10

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:2017:08_10 [2017/08/11 14:55] – [Cas tests ajoutés/supprimés] wauteletcommit:2017:08_10 [2017/08/11 16:43] (current) wautelet
Line 1: Line 1:
-===== Commit 2017-06-07 ======+===== Commit 2017-08-11 ======
  
 Ce commit est pour améliorer quelques routines liées au contact et pour mettre progressivement mes développements sur la version courante. Ce commit est pour améliorer quelques routines liées au contact et pour mettre progressivement mes développements sur la version courante.
Line 5: Line 5:
 ===== Méthode d'augmentations alternatives ===== ===== Méthode d'augmentations alternatives =====
  
-===== Robustesse des projections =====+Suite à mes derniers développements sur le Lagrangien Augmenté, j'ai proposé des méthodes d'augmentations alternatives (Nesterov, Extrapolation, Barzilai Borwein) pour accélérer la convergence du schéma classique d'Uzawa. Pour plus d'informations sur les schémas implémentés, je vous renvoie à ma présentation disponible sur orbi (http://hdl.handle.net/2268/212964).
  
-Après +Pour pouvoir utiliser les nouveaux schémas d'augmentation avec Metafor, je vous indique les différents commandes : 
  
 +<code>
 +parameters['extrapolationMethod'] = ALM_NESTREROV_EXTRAPOLATION #ALM_BARZILAIBORWEIN_EXTRAPOLATION|ALM_NESTREROV_EXTRAPOLATION|ALM_CLASSICAL_EXTRAPOLATION
 +augLagAugmentation = AugLagExtrapolationAugmentation(alm)
 +augLagAugmentation.setExtrapolationMethod(parameters['extrapolationMethod'])
 +</code>
  
 +Parmi ces schémas, celui qui semble le plus efficace à l'heure actuelle est le schéma de Nesterov. 
  
-Clairement là, il y a un problème +===== Robustesse des projections =====
  
 +=== Critère de divergence des itérations ===
  
-Finalement, j'ai ajouté la possibilité de faire des statistiques sur les projections sur une courbe ou une surface (un peu comme les EAS) :+Afin d'éviter de calculer des projections inutilement (résidu stagne ou résidu oscille ...), j'ai ajouté un critère de divergence des itérations comme celui utilisé dans les itérations mécaniques. 
  
 +=== Critère de convergence ===
  
-Ce qui donne par exemple pour le cas de la squareBox : +J'ai constaté que le terme de droite dans les critères normés sur les angles étaient trop stricts lorsque le résidu était faible ou les normes de tangentes étaient trop faibles. J'ai ajouté tout simplement une opération maximale entre la valeur 1.0 et la valeur actuelle de la norme pour passer automatiquement d'une norme relative à une norme absolue.
  
 +=== Inexact Line Search ===
  
 +J'ai constaté que l’exécution du Line Search inexacte renvoie une valeur du pas proche de zéro (ou même zéro) suite à des erreurs d'arrondi. J'ai ajouté dès lors des exceptions que l'on lance pour les cas pathologiques et l'on récupère et l'on traite dans le calcul itératif de projection. Dans ce cas, on prend une valeur du pas non nulle pour continuer le calcul itératif de la projection.
  
 +=== Interface des tolérances In/Out pour les outils de contact ===
 +
 +Après avoir lancé une série de test sur le cluster sur la squareBox et sur le sRail, j'ai été assez surpris de mes résultats sur la sensibilité aux coefficients de pénalité. En affichant les zones potentiellement en contact, j'ai constaté que des projections à priori valides n'étaient pas du tout valables ! Si il y a un problème dans l'opération de projection, les forces de contact seront complètement faussées et de là l'intégration temporelle aussi.  
    
 +Clairement là, il y a un problème suite à l'absence d'une épaisseur (artificielle) des courbes entre deux faces. Puisque nous résolvons notre calcul de projection à une tolérance près, il est fort probable, si la projection doit être sur la courbe entre les deux faces, que l'on ne trouve pas de projection suite au fait que nous sommes à chaque fois du côté extérieur de la face lors du calcul de la projection. En ajoutant une tolérance Out non nulle, le problème est en effet résolu puisque nous trouvons bel et bien une projection dans ce cas-là. Cette problématique est bel et bien connue des logiciels de CAO (notamment Parasolid).
  
 +Sans tolérance Out, on observe que des points ne sont pas en contact sur le coin de la boîte.
 +
 +{{:commit:2017:notoleranceout0000.png?800|}}
 +
 +Avec tolérance Out de 1E-3,  on observe que ces points sont en contact sur le coin de la boîte.
 +
 +{{:commit:2017:toleranceout0000.png?800|}}
 +
 +Il reste malheureusement à choisir la valeur de cette tolérance par cas-test ou pour tous les cas tests (1E-6?). Il faut savoir que les tests du type SurroundednessTest2D ou SurroundednessTest3D utilise une tolérance de 1E-6 pour le IN et OUT.
 +
 +<code>
 +skinsetPunchTool = ContactTool(skinsetPunch)
 +skinsetPunchTool.setOuterTolerance(parameters['outerTolerance'])
 +skinsetPunchTool.setInnerTolerance(parameters['innerTolerance'])
 +</code>
 +
 +=== Projection Informations ===
 +
 +Finalement, j'ai ajouté la possibilité de faire des statistiques sur les projections sur une courbe ou une surface (un peu comme les EAS) :
 +
 +<code>
 +skinsetPunchTool = ContactTool(skinsetPunch)
 +skinsetPunchTool.setProjectionInfoVerbose(True)
 +</code>
 +
 +Ce qui donne par exemple pour le cas de la squareBox (Première détection de contact) : 
 +
 +<code>
 +Projection Infos: 2897/3924 effective projections and 25/3924 failed projections 
 +(average nbNRIt = 3.59372; average nbLSIt = 2.74042; average effective nbLSIt = 2.6236)
 +</code>
  
 ===== Divers ===== ===== Divers =====
Line 59: Line 104:
 </code> </code>
  
- --- //[[gwautelet@ulg.ac.be|gaëtan]] 2017/08/10 21:59//+ --- //[[gwautelet@ulg.ac.be|gaëtan]] 2017/08/11 21:59//
  
commit/2017/08_10.1502456133.txt.gz · Last modified: 2017/08/11 14:55 by wautelet

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki