Projet

Général

Profil

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.

Statut:
Résolu
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
13/02/2017
Echéance:
% réalisé:

100%

Temps estimé:
Temps passé:

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

exemple_2D.tar (8,82 ko) exemple_2D.tar Julien Troufflard, 13/02/2017 17:55
exemple_3D.tar (3,56 ko) exemple_3D.tar Julien Troufflard, 13/02/2017 17:55
#1

Mis à jour par Julien Troufflard il y a presque 8 ans

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"""

#2

Mis à jour par Gérard Rio il y a presque 8 ans

  • % 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.

#3

Mis à jour par Gérard Rio il y a presque 8 ans

  • 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 !

#4

Mis à jour par Julien Troufflard il y a presque 8 ans

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 ?)

#5

Mis à jour par Gérard Rio il y a presque 8 ans

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.

#6

Mis à jour par Julien Troufflard il y a presque 8 ans

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

#7

Mis à jour par Gérard Rio il y a presque 8 ans

nouvel mise à jour 6.789 spécifique aux éléments 2D.

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux