Herezh++

oui c'est un peu étrange.
Si je mets un lambda de 50 c'est ok .... pour le premier incrément.
Si je diminue le K de 3000 à 30 pour la première loi, là avec un lambda de 30 ça passe bien...
C'est un peu comme si le lambda dépendait du K.
Bon... pour l'instant je ne sais pas pourquoi on observe ce type de comportement.

Après différents tests voici quelques constatations et remarques:

1)
- si on utilise seule la première loi constitutive de la loi des mélanges (celle qui a un grand module de compressibilité: K= 3000 mu= 67.415730) la convergence est normale avec lambda = 3 (comme proposé initialement dans le test)
- si on utilise seule la seconde loi, celle qui a un petit module de compressibilité et un module de cisaillement également plus faible: Kc= 22.4999999999996 mu= 0.50561797752809, il n'y a plus de convergence.

La raison est je pense, que le matériau n'est plus capable de supporter la charge imposée. On peut le voir en utilisant le mode debug = 1, et voit une expansion continue. Si par exemple, on diminue la charge d'un facteur 10, la convergence est ok toujours avec lambda = 3.

2) maintenant on travaille avec une charge divisée par 10 et avec la loi des mélanges.
- en l'état, on observe une divergence. Du coup, j'ai mis une nouvelle sortie d'info sur la loi des mélanges avec la version non rapide: lorsque:
. permet_affichage_ 6 # pour la loi des mélanges -> affichage de la proportion qui devrait être appliquée
puis affichage de la proportion écrêtée à [0,1], c-a-d la proportion réellement appliquée
. permet_affichage_ 5 # affichage uniquement de la proportion réellement appliquée

- j'ai défini une deuxième fonction mélange qui vaut toujours 0 et j'ai comparé les résultats entres la fonction mélange actuellement proposé (fonction analytique) et la fonction qui vaut 0
-->
a) avec la seconde fonction, cela converge normalement,
b) avec la fonction analytique, elle donne pour les premières itérations, une proportion très grande dans les négatives (je l'ai tracée avec gnuplot pour les valeurs proches de 0, et effectivement elle tend vers -l'infinie), du coup au début c'est essentiellement la seconde loi qui est utilisée. Mais normalement, la seconde loi converge (cf. a)) donc pourquoi on n'a pas en fin de compte de convergence ?? en fait en faisant une sortie sur un fichier log (via: HZpp_Vn-1 -f coussin_carre_10x10elts | tee toto.log, avec permet_affichage_ 5) pour le cas a) et b) puis en utilisant un tkdiff on voit qu'à partir des itérations 30 environ, quelques éléments dans le coin de la plaque, se trouve subitement avec une proportion de l'ordre de 0.2, donc avec un comportement beaucoup plus raide, et le mélange d'éléments de comportement subitement très différents, crée au final un désordre et une divergence ....

Bon... je n'ai pas de solution, mais je pense que le pb ne vient pas de la loi des mélange ni des lois hypo-élastiques, mais du type de pilotage du mélange, qui ici varie trop rapidement (a priori) ...

J'attache au message, le fichier de commande modifié que j'ai utilisé, et les deux fichiers log, et je vais mettre à jour une version non rapide (osX pour l'instant) qui contiendra les nouvelles sorties, (sera ensuite dispo pour les versions unix également)

NB: la fonction analytique a tracer sous gnuplot:
0.9*((1684.51280571469*(x+1.e-12)**9 - 9129.8486737485*(x+1.e-12)**8 + 21087.0900342347*(x+1.e-12)**7 \
- 27109.8760958237*(x+1.e-12)**6 + 21297.3202662934*(x+1.e-12)**5 - 10610.1919724422*(x+1.e-12)**4 + \
3406.33914038551*(x+1.e-12)**3 - 713.638380373004*(x+1.e-12)**2 + 99.8567080126559*(x+1.e-12) - 0.0412677193475874) \
- (x+1.e-12))/(99*(x+1.e-12))

bon, il y a bien un problème avec ma loi pour obtenir un équilibre face au chargement. ça ce n'est pas un bug Herezh.

Au hasard de mes tentatives, j'ai trouvé un bug dans la fonction 1D : F_UNION_1D.
J'ai une fonction en 3 domaines, chacun d'eux est décrit par une fonction 1D. Si je fais une loi union directement avec ces 3 lois, il ne tient pas compte de la loi du domaine 2 (dans traction_2D_C.info => loi_melange_ECHEC). Mais si je fais d'abord une loi union avec le domaine 1 et 2, puis une seconde loi union reprenant la loi union précédente + le domaine 3, ça marche (loi_melange_OK).

L'une ou l'autre loi ne fait pas planter le calcul traction_2D_C.info, c'est juste que la loi de melange n'est pas correcte. Je t'ai joint des fichiers de points avec ce que me sort Herezh pour ces deux lois (loi_melange_OK.txt et loi_melange_ECHEC.txt). à tracer avec le fichier gnu. On voit bien que le domaine 2 est squizzé à partir de x=0.02.

Exact, il y avait un décalage d'indice en lecture, sur les bornes supérieures. C'est maintenant ok dans la version 6.879
Je ferme le ticket sur le premier sujet