Anomalie #231
anisotropie par projection : probleme loi nD sur coefficient B23
Description
Gérard,
sauf erreur de mise en données, il doit y avoir un petit correctif à apporter sur la lecture du fichier .info concernant la loi de projection.
J'ai mis un exemple ci-joint. Peu importe son contenu, c'est juste une histoire de lecture du .info pour le coefficient B23 dans le cas d'une loi nD.
dans l'exemple ci-joint, j'ai les coefficients suivants :
TYPE_PROJ_ANISO_ PROJ_ORTHO
A1= 1. A2= A2_fonction_nD: fct_nD_A2
A3= 1 B12= B12_fonction_nD: fct_nD_B12
B13= B13_fonction_nD: fct_nD_B12
B23= B23_fonction_nD: fct_nD_B12
nom_repere_associe_ repere1
je souhaite donc régir les coefficients B12, B13 et B23 par une meme fonction nD. Mais Herezh me renvoie une erreur de lecture du repère.
Par contre, le calcul se lance correctement si je remplace B23 par une constante :
TYPE_PROJ_ANISO_ PROJ_ORTHO
A1= 1. A2= A2_fonction_nD: fct_nD_A2
A3= 1 B12= B12_fonction_nD: fct_nD_B12
B13= B13_fonction_nD: fct_nD_B12
B23= 1
nom_repere_associe_ repere1
J'ai également essayé en mettant une ligne vide avant nom_repere_associe_ => meme erreur.
Il y a donc un petit cas particulier à gérer dans la lecture du dernier coef.
A noter également que la doc utilisateur n'est pas à jour dans la table 216. Le texte explicatif explique bien que la syntaxe est "nom du paramètre" + _fonction_nD: contrairement au contenu de l'exemple table 216.
Fichiers
Mis à jour par Julien Troufflard il y a plus de 4 ans
- Fichier pb_val_coef.tar pb_val_coef.tar ajouté
Gérard,
a priori le problème de lecture des paramètres est plus profond que ça. Je te joins un nouvel exemple.
Dans cet exemple, j'ai une loi élastique et des paramètres de projection très simples. Les conditions limites sont un peu compliquées. Il s'agit d'une traction avec le repère d'anisotropie tourné de 45° par rapport à la direction de traction (direction X). Cela crée donc de la rotation. Les cll permettent d'exercer une traction sur un cube avec un peu de liberté en rotation.
J'ai envie de dire : bref...
L'important est de voir que les paramètres B12, B13 et B23 sont mal lus. Peut-être qu'il y a des pb sur A1, A2, A3 mais je n'ai pas testé.
Dans le répertoire joint, j'ai simulé 4 cas en modifiant B12, B13 et B23. Les paramètres suivants restent toujours les mêmes : A1=1, A2=1.5, A3=1.
Voici mes tests :
Dans les cas 1 et cas 2, je définis B12, B13 et B23 directement via une constante. Dans le cas 1, je met B12=B13=B23=1. Dans le cas 2, je mets B12=0.5 et B13=B23=1. Et pourtant ces deux cas donnent le même résultat.
Les cas 3 et cas 4 sont très différents en terme de paramètres, mais pourtant conduisent au même résultat. Dans le cas 3, je mets des constantes : B12=B13=B23=0.5. Dans le cas 4, je mets des constantes B13=B23=1 et je mets une fonction nD constante pour B12 conduisant à B12=0.5.
Dans le répertoire joint, j'ai enregistré les .maple de chaque cas. Tu peux tracer ces 4 cas sous gnuplot en lançant le fichier gnu. Et le fichier Readme rappelle les paramètres de chaque cas.
Mis à jour par Julien Troufflard il y a plus de 4 ans
oublié de préciser, mais bien évidemment, les cas 2 et cas 4 devraient donner le même résultat.
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 50
Bonjour Julien,
bien vu, il y a effectivement un test sup à mettre. C'est ok avec ton premier fichier, je vais maintenant regarder le second ...
à suivre
Mis à jour par Gérard Rio il y a plus de 4 ans
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
Mis à jour par Julien Troufflard il y a plus de 4 ans
ç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.
Mis à jour par Gérard Rio il y a plus de 4 ans
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:
#cas 1 :- A1= 1 A2= 1.5 A3= 1 B12= 1 B13= 1 B23= 1
- cas 2 :
- A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 1 B23= 1
- cas 3 :
- A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 0.5 B23= 0.5
- cas 4 :
A1= 1 A2= 1.5 A3= 1 B12= B12_fonction_nD: fct_nD_cte
B13= 1 B23= 1
Mis à jour par Julien Troufflard il y a plus de 4 ans
- Fichier Cas1_Cas2.tar Cas1_Cas2.tar ajouté
C'est étrange. Je viens de retester et non, quand je mets le cas 2 :
A1= 1 A2= 1.5 A3= 1 B12= 0.5 B13= 1 B23= 1
j'obtiens la même chose que le cas 1 :
A1= 1 A2= 1.5 A3= 1 B12= 1 B13= 1 B23= 1
J'utilise bien la version 6.936 présente dans les versions de test.
Alors du coup, ça sent la confusion de paramètres. Pour être bien sûr qu'il n'y a pas de confusion quand on commente, décommente les paramètres :
Voici en pièce jointe, le cas 1 appelé cas1.info et le cas 2 cas2.info. Le fichier gnu2 ci-joint trace la courbe. Il n'y a plus qu'à calculer cas1.info et cas2.info. Puis lancer gnuplot gnu2 => on voit bient que cas 1 = cas 2, ce qui n'est pas le fonctionnement attendu.
(NB : l'archive pièce jointe crée le répertoire Cas1_Cas2/. Et contient cas1.info et .CVisu, idem pour cas2. Et le fichier gnu2 pour gnuplot)
Mis à jour par Julien Troufflard il y a plus de 4 ans
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...
Mis à jour par Julien Troufflard il y a plus de 4 ans
si en fait, une intuition : peut-être une faute de frappe entre 12 et 13 quelque part dans le code ?
Mis à jour par Gérard Rio il y a plus de 4 ans
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.
Mis à jour par Julien Troufflard il y a plus de 4 ans
- Fichier cas2.BI cas2.BI ajouté
- Fichier cas2.maple cas2.maple ajouté
- Fichier cas4.BI cas4.BI ajouté
- Fichier cas4.maple cas4.maple ajouté
je viens de retester cas 2 (B12 fixe) et cas 4 (B12 fonction nD). J'obtiens pareil qu'avant.
ci-joint les .maple et .BI correspondant. Dans le .BI du cas 2, on a B12 = 1.
Mis à jour par Gérard Rio il y a plus de 4 ans
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
Mis à jour par Julien Troufflard il y a plus de 4 ans
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
Mis à jour par Gérard Rio il y a plus de 4 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 80 à 100