Anomalie #128
pb sortie .maple DIRECTIONS_PRINC_DEF
Ajouté par Julien Troufflard il y a presque 8 ans.
Mis à jour il y a presque 8 ans.
Description
il y a un bug dans la sortie des directions principales des déformations.
Il y a 2 exemples joint. L'un pour des éléments 2D QUADRANGLE LINEAIRE (exemple_2D.tar) et l'autre pour un élément 3D HEXAEDRE LINEAIRE
Il n'y a pas le même bug pour ces 2 exemples.
Pour le cas exemple_2D.tar, le .maple annonce les colonnes suivantes :
vec I : 5 6 7
vec II : 8 9 10
vec III : 11 12 13
or, les composantes des vecteurs I et II ont l'air étrange. Mais surtout, il n y a rien en colonnes 11 12 et 13.
J'ai pensé à un décalage de composante dû à un problème sur la dimension de l'élément (élément 2D = 2 composantes d'espace au lieu des 2 attendues).
Mais je n'ai pas pu tester en 3D. Avec exemple_3D.tar, le calcul n'aboutit pas (segmentation fault).
La sortie Gmsh fonctionne (en tout cas pour exemple_2D.tar, je n'ai pas vérifié pour le cas 3D)
Fichiers
correction dans la phrase :
"""
J'ai pensé à un décalage de composante dû à un problème sur la dimension de l'élément (élément 2D = 2 composantes d'espace au lieu des 2 attendues).
"""
je voulais écrire : """... au lieu des 3 attendues"""
- % réalisé changé de 0 à 30
Effectivement il y avait un bug sur la sortie des vecteurs propres de la déformation, et d'ailleurs également de la vitesse de déformation. Par contre c'était ok pour le tenseur des contraintes. En fait j'avais commencé une modification qui concerne le cas où la dimension de l'espace n'est pas la même que celle des éléments (ce qui est le cas ici). Et le travail était fait pour les contraintes et en cours pour le reste...
bon... c'est ok maintenant ... a priori.
Par contre, le fait qu'il n'y ait pas de direction principale en 3 est normal. Car il s'agit d'élément 2D (des quadrangles) pour lesquels seules deux directions principales existent. On peut toujours en calculer une troisième, normale aux deux autres, mais ce n'est pas la solution que j'ai choisie, car par exemple pour des éléments 1D les deux autres directions seraient arbitraires. Donc en résumé:
- pour des éléments 3D > 3 directions,
pour des éléments 2D > 2 directions
pour des éléments 1D -> une direction
Je vais maintenant regarder la partie 3D.
- Statut changé de Nouveau à Résolu
- % réalisé changé de 30 à 100
Concernant le cas 3D, il y avait un bug de dimension. C'est réparé.
Visiblement cette partie n'était pas beaucoup utilisée !!
Julien, peux-tu vérifier que tes exemples fonctionnent correctement avec la nouvelle version que je vais déposer dans le répertoire test: 6.787
NB: les vecteurs en sortie ont été normés ce qui n'était pas le cas auparavant. Par contre cela ne concerne évidemment pas les vecteurs nuls !
je réécris ici ce que je t'ai envoyé par mail :
J'ai testé la sortie des vecteurs propres avec la version 6.787.
=> Il y a bien le bon nombre de données
=> Les vecteurs sont normés
=> Mais les directions principales I et II ne sont pas orthogonales
Sur l'exemple 2D, j'obtiens les vecteurs suivants :
dir 1 : -5.379915904915e-01 -8.427968694602e-01 -1.607748078601e-02
dir 2 : 6.525447927117e-01 -7.573933266780e-01 2.325171409719e-02
le produit scalaire de ces 2 vecteurs donne un peu moins de 0.2869, au
lieu de 0.
N'y aurait-il pas une confusion dans le système de coordonnées
(coordonnées locales à l'élément ?)
nouvelle mise à jour version 6.788, le calcul des vecteurs propres associés aux valeurs propres a été revu. En espérant que cette fois c'est ok -> donc a valider.
Sur les exemples cela semble correct.
même résultat que la version 6.788 :
dir 1 : -5.379915904915e-01 -8.427968694602e-01 -1.607748078601e-02
dir 2 : 6.525447927117e-01 -7.573933266780e-01 2.325171409719e-02
=> produit scalaire = 0.2869
nouvel mise à jour 6.789 spécifique aux éléments 2D.
Formats disponibles : Atom
PDF