====== 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!).

{{:commit:2009:epl0_0.jpg|Un nouveau cont2!}} {{:commit:2009:epl0_1.jpg|}}

et voilà le code pour les curieux:
<code>
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)))
</code>


==== 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__
<code>
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
</code>
__Cas-tests__
<code>
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
</code>

 --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2009/02/06 08:51//