Commit 2009-02-06

Modifs

Loi de frottement constant

Pour comparer mes résultats ALE sur le test de double extrusion DCET (apps.ale.dCupExtrusion), j'ai dû programmer une loi de frottement de type Tresca où le frottement est une constante indépendante de la pression. $\sigma_T \leq m\,\sigma_0^Y$ où $\sigma_T$ est la contrainte de frottement, $ m $ est le coefficient de frottement et $\sigma_0^Y$ est la containte d'écoulement en cisaillement du matériau (qui vaut la limite en traction / $\sqrt{3}$ dans le cas de VM).

Pour l'implémentation, j'ai juste créé une nouvelle loi TrescaContactMaterial qui ressemble fort à CoulombContactMaterial. J'ai préféré ne pas ajouter des if dans la loi de Coulomb (j'en ai discuté avec Luc). Pour la raideur, je me suis rendu compte que la raideur de Coulomb était codée directement dans l'élément de contact. J'ai donc créé de nouvelles fonctions virtuelles pour que l'élément demande au matériau de calculer la raideur et non qu'il présuppose du Coulomb (!).

Nouveaux tests:

apps.qs.trescaFriction: bête test de frottement entre un bloc et un plan avec sortie des résultantes.
apps.ale.dCupExtrusion: nouvelle mouture du test DCET avec Loi de Tresca et nouvelles géométries de poinçon.

Loadings améliorés

Pour mes tests ALE de planage, j'ai un sérieux problème de propagation de crasses venant des conditions aux limites dans ma solution. Au final, une petite pertu de mes conditions aux limites vient initiialiser mes défos de Green Lagrange avec des valeurs très différentes de 0 et j'observe une sorte de décalage dans mon profil d'allongement. Pour résoudre le problème, j'ai donc imaginé d'imposer mon tenseur F en entrée égal à l'unité… mais problème: la manière dont la gestion des CLs ALE est codée est un vieux machin qui date de bien avant l'époque python et je ne peux pas choisir d'imposer uniquement un ensemble réduit de valeurs en entrée. Soit j'impose tout, soit j'impose rien. et dans ce cas-ci, j'aimerait laisser le tenseur des contrainte se calculer automatiquement.

Pour imposer mes conditions aux limites ALE de manière propre, j'ai ajouté la possibilité de prescrire un champ sur un maillage via le LoadingSet. Il est donc maintenant possible de définir via l' InitialConditionSet un champ scalaire hétérogène aux points de Gauss d'éléments finis. La manière est identique à ce que j'avais fait pour les grandeurs nodales. Ca peut être utile à tout le monde donc lisez la suite…

Nouvelle hiérarchie Loading

Pour ce faire, j'ai remanié la structure des classes Loading/LoadingSet.

Loading est une nouvelle classe qui ne contient que la gestion de la fonction d'évolution (le “driver”).
De Loading dérivent 3 classes: DBLoading, GPLoading et ElementLoading.
DBLoading est l'ancien Loading: un chargement qui s'applique sur la DB via un objet géométrique. Les chargements nodaux (uniforme, rotation, radial) dérivent de cette classe et ne manipulent au final que des données stockées aux noeuds et des points.
GPLoading est une nouvelle classe qui permet d'accéder aux points de Gauss des éléments générés par une interaction donnée. J'utilise pour ce faire l'interface que j'avais définie pour l'ALE au niveau de l'élément.
ElementLoading permet d'accéder aux noeuds d'éléments à travers une Interaction. C'est ce que j'utilise pour mes CLs nodales en ALE.
Au niveau des conteneurs, LoadingSet dérive (toujours) de LoadingSetBase et ne peut contenir que des objets DBLoading. J'ai fait passer tout ce qui gère les fixations de LoadingSetBase à LoadingSet (on ne peut pas encore fixer des valeurs aux point de Gauss).
InitialConditionSet dérive aussi de LoadingSetBase et peut maintenant contenir n'importe quel type de Loading (DB ou GP).

Gestion des conditions initiales

Pour l'initialisation, c'est toujours fait dans le toDofSet de Domain mais j'ai dû découper le toDofSet de l'élément en un toDofSet et un initialise. La première routine, alloue le locel et les points de Gauss~; la seconde remplit initialise l'élément. Sans ce découpage, la matrice de capacité thermique par exemple n'est pas correctement initialisée. Cette seconde routine est à nouveau appelée lors du démarrage de l'intégration (l'ancien contactInitialisation devient elementsInitialisation).

Avant:

Domain::toDofSet
- application des CLs (aux noeuds)
- création des éléments
- Element::toDofSet()
  - allocation des GP / init du locel
  - remplissage des GPs, calcul des matrices M, C élémentaires
TimeIntegration::initialise()
- ContactElement::detectContact()

Maintenant:

Domain::toDofSet()
- création des éléments
- Element::toDofSet()
  - allocation des GP / init du locel
  - VolumeElement::initialise(): pas réussi à m'en débarrasser car il le faut pour le calcul des matrices des masses en restart.
- application des CLs (aux noeuds et points de Gauss)
- Element::initialise()
  - remplissage des GPs, calcul des matrices M, C élémentaires
TimeIntegration::initialise()
- Element::initialise()

Exemple

En application, pour la batterie, j'ai créé une super variante de cont2: cont2ecroui où un morceau du bloc est déjà bien écroui et est visiblement plus raide que le reste du bloc.

Vu que c'est programmé de manière générique, on peut aussi s'amuser à définir des contraintes initiales hétérogènes avec le même système (ou même un IF_GRAIN_SIZE, soyons fou!).

et voilà le code pour les curieux:

def tfct(x, y):
    cx = 1./2
    cy = 1./2
    R  = 0.3
    if (cx-x)*(cx-x)+(cy-y)*(cy-y)-R*R<0:
        return 2.
    return 0.
    
epl0fct = PythonMultiParameterFunction(tfct, 2)
metafor.getInitialConditionSet().define(app, IF_EPL, 1.0, epl0fct , FieldList(Field1D(TX,AB), Field1D(TY,AB)))

ALE

Calcul du volume avant et après remaillage. Ceci permet de suivre l'évolution du volume au cours du calcul et vérifier qu'il reste +/- constant si on est en plasticité VM.
Conditions limites variables CL=CL(x,y,z,t)
refonte de l'élément de condition aux limites
suppression des codes BC_
modification du test convRot: celui-ci teste maintenant un champ hétérogène de defos plastiques initiales.
ajout de varBC: test des conditions aux limites variables où $f(x,y,t)=y\sin(\omega t)$

Tests Copra

J'ai ajouté les tests de profilage NotInBattery dans la batterie en n'en faisant qu'un import. Ca permet de s'assurer que la moulinette Copra fonctionne bien sur tous les tests. Ces tests sortent un TSC-EXT bidon si l'import s'est effectué correctement.

Projet

Fichiers ajoutés/supprimés

Source

mtFEMBase/DBLoading.cpp	added
mtFEMBase/ElementLoading.cpp	added
mtFEMBase/GPLoading.cpp	added
mtFEMBase/LoadingType.cpp	added
mtMaterials/boundaries/TrescaContactMaterial.cpp	added
mtFEMBase/DBLoading.h	added
mtFEMBase/ElementLoading.h	added
mtFEMBase/GPLoading.h	added
mtFEMBase/LoadingType.h	added
mtMaterials/boundaries/TrescaContactMaterial.h	added

Cas-tests

apps/ale/varBC.py	added
apps/qs/cont2ecroui.py	added
apps/qs/trescaFriction.py	added
geniso/tests/py/__init__.py	added
apps/ale/entonnoir.py	deleted

arcelor/tests/copraLarge	added (+)
arcelor/tests/copraLarge/profilageTraverse.py	added (+)
arcelor/tests/copraProfiling5NotInBattery	deleted
arcelor/tests/copraProfiling5NotInBattery/__init__.py	deleted
arcelor/tests/copraProfiling5NotInBattery/profilageBavolet.py	deleted

— Romain BOMAN 2009/02/06 08:51

Metafor

Table of Contents