Projet

Général

Profil

Anomalie #211

Erreur3 : le determinant est nulle !

Ajouté par Frank Petitjean il y a environ 5 ans. Mis à jour il y a environ 5 ans.

Statut:
Résolu
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
14/09/2019
Echéance:
% réalisé:

100%

Temps estimé:
Temps passé:

Description

Gérard,

Je reprends des calculs un peu complexes de BSO avec le couplage hydro (beaucoup de fonctions nD !).

Comme toujours je commence par faire tourner Herezh un ancien modèle qui a bien fonctionné. La version version utilisée pour ces calculs est la 6.861.

Avec la version 6.907 le calcul se déroule normalement mais dès le 2e incrément j'ai les lignes :

_ ... convergence en 4767 iterations
Erreur3 : le determinant est nulle !
Mat_pleine::Inverse() ** warning: erreur en ecriture pour la visualisation au fil du calcul_

et les fichiers résultats ne sont plus écrits !

Je te joins mon modèle.
Merci
Frank


Fichiers

BSO_couplageHydro.7z (19,7 ko) BSO_couplageHydro.7z Frank Petitjean, 14/09/2019 13:40
log.7z (2,42 Mo) log.7z Frank Petitjean, 16/09/2019 11:38
#1

Mis à jour par Gérard Rio il y a environ 5 ans

  • % réalisé changé de 0 à 10

Bonjour Frank,
j'ai bien un pb, mais pas au 2ième incrément ?? pour moi, cela passe bien du 1 au 2ième qui converge à 3331 itérations puis on passe au 3ième et j'ai un pb à l'itération 544 ????
- a priori il y a 47 noeuds qui ont une masse nulle ?? je ne sais pas si c'est la raison du pb, mais a priori ce n'est pas bon de garder des noeuds avec une masse nulle.
Je continue de regarder

#2

Mis à jour par Frank Petitjean il y a environ 5 ans

Ton calcul ne se comporte pas comme le mien ! J'utilise pourtant la version 6.907...

Je n'ai aucun problème de convergence et le calcul parait aller au bout. Par contre je n'ai que la sortie à la fin de l'incrément 1. A la fin de l'incrément 2 apparait cette erreur3 qui se répète jusqu'à la fin du calcul.

Je te joins mon fichier log.

Frank

#3

Mis à jour par Gérard Rio il y a environ 5 ans

  • Statut changé de Nouveau à Résolu
  • % réalisé changé de 10 à 100

Je pense avoir résolu le pb : en fait 2 pb.
1) le premier concerne la sortie pour le post-traitement, des éléments biellettes, dans un repère 3D. J'ai modifié la construction du repère local associé, et il y avait un cas où les vecteurs n'étaient pas indépendants. Du coup j'ai changé de méthode (la méthode implantée était simple ... mais n'était pas correcte dans certains cas: cas qui apparaissent dans ton test. Le traitement est maintenant plus générique et vérifie la non-singularité des matrices correspondantes aux repères créés (qui servent pour les changements de base de post-traitement).
2) le second concerne le contact: après un restart et/ou un suite_point_info_ les frontières étaient (re) calculées au cas où cela n'aurait pas été effectué auparavant suite à un contact non actif.
Du coup, la méthodologie retenue est la suivante :
- la présence d'1 ou plusieurs maillages esclaves est "nécessaire" pour initialiser un contact potentiel. Le contact peut très bien ne pas être actif. Par contre si aucun maillage esclave n'est déclaré, l'activation du contact conduit à une erreur.
- il n'est pas possible d'introduire des maillages esclaves et éventuellement des zones particulières de contact au moment d'un restart ou un suite_point_info_
- par contre il est toujours possible de modifier l'activité du contact (0 ou autres), les types, et en faite tous les paramètres de contact au moment d'un restart ou après un suite_point_info_

En conséquence, les frontières sont calculées une seule fois en phase d'initialisation.

Avec ces modifications, le calcul se déroule correctement. Ce sera dispo dans la version >= 6.910

#4

Mis à jour par Frank Petitjean il y a environ 5 ans

Merci Gérard pour cette correction express. J'ai eu depuis mon post autre cas avec cette même erreur, et sans contact (ballon entier). J'avais des résultats avec un lambda=1 et avec un lambda=2 -> Erreur3 et pas de résultat ! C'était clairement un problème relatif au post-traitement.

J'espère que la maintenance du code sera maintenu encore pendant de longues années sinon...

#5

Mis à jour par Gérard Rio il y a environ 5 ans

Effectivement, le pb de post-traitement était général. Le pb concernant le contact n'était pas toujours présent. En particulier, j'avais forcé une convergence rapide avec ton test et dans ce cas là je n'avais pas de pb ... du coup j'ai été obligé d'utiliser les paramètres initiaux ce qui conduit à des temps de calcul long ! mais les résultats sont spectaculaires: -> ex la déformée en descente. La mise en données est bien fournie !! peut-être que ce serait intéressant de mettre les courbes et fonctions nD dans un fichier à part. Il est également possible d'inclure directement la def de fonctions nD dans la déclaration de fonction combinée, c'est peut-être une méthode pour simplifier ?
Bon... j'espère que je n'aurai plus à intervenir sur la méthodo générale du contact car c'est un peu chronophage !

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux