Herez++_test

bonjour Frank,
ci-joint, une première série de tests et résultats pour la réponse concernant la relaxation dynamique.
La suite dans une prochaine réponse.
@+
-------------------------------------

Essai du cas model01a-rdy.info:
-> avec les paramètres actuels, effectivement ne converge pas
on intervient au niveau des paramètres de relaxation:
- avec lambda= 1.6 -> convergence en 125 itérations
- avec lambda= 1. -> divergence
- avec lambda= 1.2 -> convergence en 71 itérations
- avec lambda= 1.1 -> convergence en 74 itérations

1) Première conclusion: donc au bilan, avec un lambda= entre 1.2 et 1.6 ça à l'air d'être
ok pour un maillage à 2 éléments et ce type de loi de comportement
Intérêt de l'utilisation de la relaxation: on peut ne pas bloquer les UX et UY
pour l'ensemble des noeuds

1. < maillage_02.her

1. cas d'un maillage avec 100 éléments
   < barre100.her
   def_mouvement_solide_initiaux_
   mouvement_solide_ # def de mouvements solides
   centre_= 0. 0. 0.
   rotation_= 0. 90 0. en_degre_
   fin_mouvement_solide_

là cela ne converge pas avec lambda= 1.2,
bon... on augmente le lambda : à 2.6 par exemple cela converge en 592 itérations
avec 3.6 -> 187 itérations
en mettant le paramètre débug à 1 dans la relaxation:
...

1. variable_emplacement
   typeCalRelaxation= 1 lambda= 3.6 type_calcul_mass= 2 option_recalcul_mass= 0
   parametre_calcul_de_la_masse_ casMass_relax= 3

mode_debug_= 1 # fréquence de sortie des itérations (.CVisu)
...
On voit clairement l'évolution de l'élongation

On reprend le maillage avec 2 éléments, et avec lambda= 3.6 -> convergence en 50 itérations
bon... on pourrait donc garder 3.6

On prend un nouveau maillage de 1000 éléments
avec lambda= 3.6 > plein de mini relaxation => pas la bonne valeur, -> on augmente lambda
avec lambda= 5.6 -> convergence en 6648 : c'est beaucoup plus long, mais il faut voir que
c'est très instable, donc c'est peut-être normal ??

2) deuxième conclusion: pour un maillage avec plus d'éléments, il faut jouer sur le
paramètre lambda pour obtenir une convergence, dans le cadre de la loi proposée.

On utilise le fichier model01a-sta.info
NB: il est demandé une précision de 1.e-6, avec une norme relative:
-> c'est une contrainte forte ! pour comparaison, la valeur par défaut proposée par
Abaqus est 5.e-3, et dans herezh c'est 1.e-3. Donc la valeur demandée ici est 1000 fois
plus faible. J'ai certaines fois remarqué que lors de l'utilisation de lois non linéaires
il était difficile de descendre en dessous d'une précision de 1.e-5, compte tenu
de la précision utilisée pour résoudre l'équation constitutive de la loi de comportement.
Ceci étant, cela n'a pas d'importance pour la suite qui elle est faite avec la précision par
défaut donc de 1.e-3.

Passage en dynamique implicite: -> ok, puis non-convergence due a priori à l'absence de réaction
en compression

-> si je me réfère au fichier log, j'ai l'impression que pendant les itérations de newton
  la sangle passe alternativement en compression-traction-compression. Ces oscillations
  font que l'équilibre ne peut pas être atteint. 
  Je crois qu'il faudrait un passage plus progressif traction-compression, ce qui devrait
  permettre une convergence même avec une loi nulle... Ici la discontinuité du 
  comportement ne permet pas au processus, qui doit être finalement assez progressif, de Newton
  de converger.

Passage en dynamique explicite:
effectivement le temps de calcul est long. Le pas de temps critique est calculé à partir
de la raideur du matériau et de sa masse. Ici la raideur est bizarrement calculée.
Tout d'abord pour t=0, la raideur de la partie élastique est nulle et celle de la partie
visqueuse est infinie ... Ensuite quand on rentre en compression la raideur devient
entièrement nulle ...
Dans tous les cas ce n'est pas très bon d'avoir 0 comme raideur dans un calcul explicite
relativement au calcul du pas de temps critique.

Une première idée, on remplace la loi de Newton pure par un maxwell avec un module d'Young grand,
  essai avec un module : E= 1.5e10, donc 10 fois celui de la branche purement élastique
  > donne un calcul très rapide -> le pas de temps critique = 0.000522088 (à la fin)
  au lieu de e-7 ! -> calcul a 1.7s en 1343 incréments
  -> avec un module de E= 1.5e11, idem, très rapide et les résultats sont globalement identiques
  --> Donc je pense que c'est une solution intéressante à creuser.

Non-respect du critère de contrainte nulle en compression:
Effectivement on observe des efforts en compression non nuls !
En fait il n'y a pas d'erreur. Pour le constater, il faut tout d'abord sortir les infos
pour tous les incréments (et non 1 incrément / 10 ou 100). Dans ce cas on observe des
oscillations près de 0. La raison est la suivante:
- la fonction de pondération est calculée sur la valeur de la contrainte à t, et elle
s'applique à t+delta t. C'est un calcul explicite. Donc on peut constater que dans le cas
présent cela ne conduit pas à de bons résultats.
- une solution est d'utiliser la valeur de la déformation eps11. La valeur utilisée dans
ce cas est bien en phase avec celle de la contrainte. Cette possibilité n'est pas présente
dans la version 6.675, je l'ai intégré dans une nouvelle version (> 6.675)
En fait dans le programme
c'est la valeur locale de la déformation qui est utilisée, mais le signe est identique.
-> Cela fonctionne a priori correctement sauf que la contrainte est en retard sur la déformation
et donc on observe un peu de contraintes négatives au moment ou la déformation n'est pas
encore négative.

Nouvel essai avec l'implicite avec la nouvelle loi et pondération:
-> là maintenant cela fonctionne avec un pas de temps de 0.001. Cela ne donne pas exactement
les mêmes déformations en fonction du temps ? je ne sais pas pourquoi. J'aurai plutôt
tendance à faire confiance aux résultats explicites, mais c'est juste une intuition.