====== Commit 2013-11-29 ====== ===== Modifications ===== ==== Méthode de contact conservative ==== J'ai adapté le nom des méthodes de contact conservatives : * CONSERVINGCONTACTMETHOD_ARMEROPETOCZ => CCM_ARMEROPETOCZ * CONSERVINGCONTACTMETHOD_LAURSEN => CCM_LAURSEN * CONSERVINGCONTACTMETHOD_LOVE => CCM_LOVE La méthode de Laursen et celle de Love sont non validées (les équations implémentées ne correspondent pas à ce qui décrit dans les articles de référence !). J'ai inséré un FATAL ERROR pour empêcher l' utilisateur de les utiliser ! Également, j'ai supprimé tous les cas-tests de la batterie qui utilisent ces méthodes là en pénalité classique et en lagrangian augmenté. Pour toute personne intéressée, les articles de référence sont les suivants : * Improved implicit integrators for transient impact problems-dynamic frictional dissipation within an admissible conserving framework, G.R. Love, T.A. Laursen. * Design of energy conserving algorithms for frictionless dynamic contact problems, T.A. Laursen, V. Chawla Pour être sur et certain que les algorithmes de contact conservatif fonctionnent correctement, il faudrait d'une part corriger les méthodes de contact (Modifications du contenu des méthodes de contact et les calculs des composantes des forces dans les matériaux de contact) et d'autre part s'assurer que le schéma d'intégration conservatif correspond bel et bien à celui utilisé dans ces articles de référence. Le cas de test de référence de l'impact d'une barre contre un plan rigide est repris dans l'article Formulation and analysis of conserving algorithms for frictionless dynamic contact/impact problems, F. Armero, E. Petöcz pour pouvoir valider les méthodes. Finalement, j'ai constaté que le statut de contact lors des méthodes de contact ne correspond pas à l'état réel du statut de contact. Par exemple, lors de la phase "initIteration" ou "contactDetection", le statut de contact va prendre une valeur "True" si le gap normal est négatif (si UNILATERAL_NEGATIF). Lors de la phase de calcul de la force de contact, plus précisément lors de l'évaluation de la composante normale de la force de contact, puisque le gap dynamique est positif( et donc nous ne sommes pas en contact), on indique une valeur nulle de la force de contact sans altérer le statut de contact. Il aurait été bien plus facile de s'assurer que le statut de contact soit bel et bien le bon avant de procéder au calcul des forces de contact et de la matrice de raideur de contact... Dès lors, on fait la correction du statut du contact (en contact ou pas) lors de l'étape setStep() ce qui rend encore plus compliqué la lisibilité du code source ... et en plus l'extracteur du statut de contact sort une valeur erronée ! ==== Méthode du Lagrangian Augmenté ==== J'ai nettoyé la classe Augmented Lagrangian Manager. Notamment, cet objet n'apparait plus par défaut dans l'objet Metafor. alm=AugmentatedLagrangianManager(metafor) alm.setMaxNbOfIterations(itma) alm.setAugLagMethodCriterion(criterion) Inputs: | ''metafor'' | Référence vers une analyse metafor | | ''itma'' | Nombre d'augmentations max (10 par défaut) | |''criterion''| Critère d'arrêt | | | ''ALM_CRITERION_NO = default '' | | | ''ALM_CRITERION_GEO'' | Le critère d'arrêt ALM_CRITERION_NO correspond à un nombre d'augmentation imposé par pas de temps. Le critère d'arrêt ALM_CRITERION_GEO correspond à une tolérance géométrique satisfaite en chaque nœud en contact par pas de temps. Si on ne parvient pas à atteindre la tolérance géométrique donnée en un nombre d'augmentation max, on recommence la calcul avec un pas de temps plus petit. J'ai ajouté les matériaux suivants AugLagFrictionLessMaterial, AugLagStickingContactMaterial et AugLagCoulombContactMaterial. Les tolérances géométriques sur le gap normal et le gap tangentiel sont insérées au niveau du matériau ! Les lagrangians augmentés ne sont plus dans le GP State des matériaux de contact de type pénalité (J'ai éliminé trois valeurs doubles !). J'ai incrémenté la version des archives et il est possible de faire des restarts avec une version antérieures ! J'ai déplacé la variable indiquant le nombre d'itération avant la première augmentation dans la classe Augmented Lagrangian Manager et ajouté la fonction getNumberOfIterationsForTimeStepEvaluation() dans la classe TimeIntegration. Il reste à mettre au point une règle heuristique de manière à adapter le pas de temps sur base du nombre d'augmentations par pas de temps et du nombre d'itérations mécaniques et/ou thermique. Il n'existe pas de test en interne (lors de la phase d'initialisation du schéma d'intégration temporelle) qui vérifie la présence du Augmented Lagrangian Manager et d'au moins un matériau du type AugLag pour une interaction de contact. A l'heure actuelle, j'ai désactivé en dur dans le code source les deux fonctionnalités suivantes : * diminution des lagrangians augmentés selon une règle heuristique, si on a une perte de contact au cours des itérations mécaniques, * extrapolation du lagrangian augmenté normal lors de la phase d'augmentation. ===== Perspectives ===== Méthode du lagrangien augmenté : * Débugger la méthode * Ajout de nouveaux critères d'arrêt * Ajoutez des cas-tests simples pour vérifier la méthode du Lagrangian augmenté * Ajoutez la contribution géométrique de la matrice de raideur tangente dans le cas rigid-défo (2D et 3D) * Ajout des cas test de référence de l'article de J. C. Simo and T. A. Laursen, 1990 * Mettre à jour l'aire de contact nodale au cours des augmentations ===== Fichiers ajoutés/supprimés ====== [r]: [a]:mtMaterials/boundaries/AugLagStickingContactGpState.h [a]:mtMaterials/boundaries/AugLagStickingContactGpState.cpp [a]:mtMaterials/boundaries/AugLagStickingContactMaterial.h [a]:mtMaterials/boundaries/AugLagStickingContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagCoulombContactGpState.h [a]:mtMaterials/boundaries/AugLagCoulombContactGpState.cpp [a]:mtMaterials/boundaries/AugLagCoulombContactMaterial.h [a]:mtMaterials/boundaries/AugLagCoulombContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagFrictionLessContactGpState.h [a]:mtMaterials/boundaries/AugLagFrictionLessContactGpState.cpp [a]:mtMaterials/boundaries/AugLagFrictionLessContactMaterial.h [a]:mtMaterials/boundaries/AugLagFrictionLessContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagMechanicalContactGpState.h [a]:mtMaterials/boundaries/AugLagMechanicalContactGpState.cpp [a]:mtMaterials/boundaries/AugLagMechanicalContactMaterial.h [a]:mtMaterials/boundaries/AugLagMechanicalContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagNormalMechanicalContactGpState.h [a]:mtMaterials/boundaries/AugLagNormalMechanicalContactGpState.cpp [a]:mtMaterials/boundaries/AugLagNormalMechanicalContactMaterial.h [a]:mtMaterials/boundaries/AugLagNormalMechanicalContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagFrictionalMechanicalContactGpState.h [a]:mtMaterials/boundaries/AugLagFrictionalMechanicalContactGpState.cpp [a]:mtMaterials/boundaries/AugLagFrictionalMechanicalContactMaterial.h [a]:mtMaterials/boundaries/AugLagFrictionalMechanicalContactMaterial.cpp [a]:mtMaterials/boundaries/AugLagTangentialMechanicalContactGpState.h [a]:mtMaterials/boundaries/AugLagTangentialMechanicalContactGpState.cpp [a]:mtMaterials/boundaries/AugLagTangentialMechanicalContactMaterial.h [a]:mtMaterials/boundaries/AugLagTangentialMechanicalContactMaterial.cpp [a]:mtMaterials/boundaries/PenaltyMechanicalContactGpState.h [a]:mtMaterials/boundaries/PenaltyMechanicalContactGpState.cpp [a]:mtMaterials/boundaries/PenaltyMechanicalContactMaterial.h [a]:mtMaterials/boundaries/PenaltyMechanicalContactMaterial.cpp ===== Tests ajoutés/supprimés ===== [r]:apps/bImp/contactLaursen.py [r]:apps/bImp/contactLaursenAugLag.py [r]:apps/bImp/contactLove.py [r]:apps/bImp/contactLoveAugLag.py [r]:apps/bImp/cylElastFrotLaursen.py [r]:apps/bImp/cylElastFrotLaursenAugLag.py [r]:apps/bImp/cylPlastLaursen.py [r]:apps/bImp/cylPlastLaursenAugLag.py [r]:apps/imp/contact3dDefoDefoAugLag1.py [r]:apps/imp/contact3dDefoDefoAugLag2.py [r]:apps/imp/contactAugLag1.py [r]:apps/imp/contactAugLag2.py [r]:apps/imp/contactAugLag3.py [a]: --- //[[gwautelet@ulg.ac.be|Gaëtan WAUTELET]] 2013/11/29//