Herezh++

oublié de préciser, mais bien évidemment, les cas 2 et cas 4 devraient donner le même résultat.

J'ai effectué le second test et dans tous les cas j'obtiens bien après lecture, les coefs indiqués dans la mise en données.
Le plus simple pour le vérifier est d'ouvrir le .BI et de rechercher le mot clé: anisotrope : on peut lire les coefs qu'Herezh à lus.
Je mets à jour dans la version 6.936

ça ne fonctionne toujours pas pour le second test.

Pour une raison que je ne comprends pas, on n'obtient pas le même résultat selon que l'on mette B12=0.5 en dur (cas 2) ou que l'on mette B12=0.5 via une fonction nD (cas 4).

Dans ce cas, si la lecture des coefs fonctionne avec la nouvelle version, alors le problème est ailleurs que dans la lecture du .info.

et bien si... moi j'obtiens la même chose si B12=0.5 ou si c'est avec la fonction !
c-a-d les cas 2 et 4:

peux-tu re-vérifier ?

NB: pour mémoire:

1. A1= 1 A2= 1.5 A3= 1 B12= 1 B13= 1 B23= 1

1. cas 2 :
2. A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 1 B23= 1

1. cas 3 :
2. A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 0.5 B23= 0.5

1. cas 4 :
   A1= 1 A2= 1.5 A3= 1 B12= B12_fonction_nD: fct_nD_cte
   B13= 1 B23= 1

j'ai oublié préciser. Ce point ne me bloque pas vraiment a priori. Comme le cas 4 fonctionne, j'ai réussi à avancer pour le PEL60. Mais bon, à voir quand même, ça reste un bug à régler pour m'assurer que ma loi PEL60 anisotrope est dans un cas normal de fonctionnement.

Parce que c'est très bizarre sur l'exemple que je t'ai envoyé.
Tout d'abord, A SIGNALER que je me suis trompé dans le fichier gnu2 précédent. J'ai oublié de mettre "_princ" dans les noms de .maple. A CORRIGER.

une fois cette correction faite, on voit bien que cas 1 = cas 2 dans mon envoi précédent. Mais c'est encore plus bizarre que ça. Ce cas de traction est tel qu'il y a du cisaillement dans le plan 12. Mais aussi, les cisaillement 13 et 23 n'interviennent pas. Ils sont sensés être nuls. Et de toute façon, même non nul, ils n'auraient théoriquement aucune influence sur la contrainte 11. Mais sur ce point je raisonne dans le cas de repères orthonormés, ce qui est de moins en moins le cas pour le repère aniso entrainé au cours du calcul. Mais bon, si c'était un problème de grande déf, on le verrait. C'est pas ça le souci.

C'est donc cette contrainte 11 qui est tracé dans le fichier gnuplot. La contrainte 11 n'est influencée que par A1, A2 et B12 en très très grande majorité.

J'ai retesté 3 nouveaux cas. Voici la liste :
- rappel cas 1 : A1= 1 A2= 1.5 A3= 1 B12= 1 B13= 1 B23= 1
- rappel cas 2 : A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 1 B23= 1
- rappel cas 3 : A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 0.5 B23= 0.5
- rappel cas 4 : A1= 1 A2= 1.5 A3= 1 B12= fonction nD=0.5 B13= 1 B23= 1
- NOUVEAU cas 5 : A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 0.5 B23= 1
- NOUVEAU cas 6 : A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 1 B23= 0.5
- NOUVEAU cas 7 : A1= 1 A2= 1.5 A3= 1 B12= 1 B13= 0.5 B23= 0.5

J'obtiens :
=> cas 1 = cas 2 = cas 6
=> cas 3 = cas 4 = cas 5 = cas 7

La preuve la plus flagrante du fonctionnement anormal reste le fait que l'on n'ait pas : cas 2 = cas 4. Sans ce cas, la mise en données (conditions limites par exemple) aurait pu être en cause. Mais a priori non.

Le fait que cas 5 = cas 7 mais pas cas 6, ça ajoute encore à mon incompréhension du pb. Au final, je ne vois pas où pourrait être l'erreur. Pas d'intuition cette fois...

si en fait, une intuition : peut-être une faute de frappe entre 12 et 13 quelque part dans le code ?

Julien, peux-tu répondre à ma précédente question: est-ce que tu obtiens bien les mêmes valeurs avec B12 fixe et B12 la fct nD
Ceci de manière à sérier les pb.
Ensuite je regarderai les autres pb.

En fait cela fonctionnait avec la version avec vérification, mais pas avec la version rapide !!
La raison venait d'un #define dans une méthode qui n'a rien n'a voir avec la loi de projection... Pas facile à trouver.
Bon, du coup pour éviter ce genre de mauvaise blague pour la suite, tous les #define de type basique ont été supprimé et remplacé par des pointeurs ad hoc -> ok maintenant a priori avec la version 6.937 : versions avec vérif ou non

ok. J'ai repassé tous les cas et tout est conforme.

cas 1 = cas 7 (tous ceux avec B12=1)
cas 2 = 3 4 5 et 6 (tous ceux avec B12=0.5 y compris fonction nD)

bonne nouvelle si cela a contribué à pointer et solutionner un nouveau type d'erreur