Anomalie #331
calcul ne s'arrête pas malgré une divergence
Description
Gérard,
j'ai un calcul qui ne s'arrête pas alors qu'il remplit tous les critères pour le faire.
En gros, je fais un calcul de gonflage. Comme je ne sais pas à l'avance si l'enveloppe supportera la pression, je m'attends à ce qu'il puisse rencontrer une divergence ou non. Je souhaite qu'il s'arrête dès la première divergence.
le problème de ces calculs infinis, c'est entre-autre que l'affichage redirigé vers un fichier va générer un énorme fichier de redirection produisant parfois le crash de l'ordi (c'est d'ailleurs ce qui m'a enfin poussé à faire ce ticket alors que je connais ce pb depuis un moment).
La divergence est typiquement repérée par un jacobien négatif ou infini. J'ai donc mis :
CAS_JACOBIEN_NEGATIF 2
c'est-à-dire => divergence dès le premier jacobien rencontré
Je fais également en sorte que le pas de temps ne puisse être modifié :
TYPE_DE_PILOTAGE AUCUN_PILOTAGE
et en plus au cas où, je mets :
DELTAtMINI = DELTAtMAXI = DELTAt
avec ça normalement, s'il diverge, il ne peut modifier son pas de temps => il doit donc s'arrêter.
Mais dans mon calcul, ce n'est pas le cas. Il met un message de non convergence, dit qu'il ne peut pas modifier le pas de temps mais recommence l'incrément quand même. Et cette séquence se reproduit indéfiniment.
J'ai essayé une astuce. Comme je sais à l'avance combien d'incréments je vais faire au maximum, j'ai essayé le paramètre MAX_ESSAI_INCRE.
Dans mon exemple, il diverge à l'incrément 17. Si je mets MAX_ESSAI_INCRE égal à 17 ou 18, effectivement il s'arrête (pas normalement mais il s'arrête quand même). Mais si je mets 19 ou plus, je retombe sur un calcul qui boucle à l'infini.
L'exemple joint est en relaxation dynamique. Je ne sais pas si le problème est général aux calculs de statique.
merci d'avance
Julien
Fichiers
Mis à jour par Gérard Rio il y a presque 2 ans
- Statut changé de Nouveau à En cours
- % réalisé changé de 0 à 10
avec le calcul non fast (donc avec le plus de vérif) a priori le calcul s'arrête normalement.
La raison de la divergence est en amont du jacobien infini il s'agit d'un pb d'inversion de matrice avec déterminant nul. Dans le cas non fast, il y a une vérification du déterminant et ... cette vérif est suspendu en fast ! du coup des pb en chaîne.
J'ai assigné la vérif quelque soit la version et là c'est ok.
Mais cela ne répond pas au pb initial !!
affaire à suivre ...
Mis à jour par Gérard Rio il y a presque 2 ans
- % réalisé changé de 10 à 90
J'ai trouvé un fct que je ne connaissais pas: lorsque l'on met un switch à l'intérieur d'une boucle: un break dans le switch fait sortir du switch, mais pas de la boucle ?? C'est sans peut-être normal, mais je pensais une sortie de boucle.
Bref, j'avais donc ce type de situation dans la gestion de l'arrêt d'exécution avec de la relaxation dynamique et cela neutralisait l'arrêt demandé !
A priori c'est propre à la relaxation dynamique.
Concernant l'erreur de déterminant, finalement j'ai remis la directive de précompilation pour éviter une avalanche de messages d'erreur en version fast, sachant qu'en fait:
1) cela conduisait de toute manière à un arrêt global via le test sur le jacobien
2) les messages ne me paraissent pas pertinents dans la version fast contrairement à la version non fast qui permet d'avoir beaucoup plus d'infos supplémentaires qui dans ce cas rendent plus intelligible le message de déterminant nul (utilisé pour calculer l'inversion d'un tenseur).
la nouvelle version V 7.007 intègre les modifs
Julien peux-tu me dire si c'est ok ?
Mis à jour par Gérard Rio il y a presque 2 ans
- Statut changé de En cours à Résolu
- % réalisé changé de 90 à 100
Mis à jour par Julien Troufflard il y a presque 2 ans
désolé de déterrer ce ticket.
En fait, je n'avais pas remarqué un pb sur les sorties Gmsh et maple dans le cas d'une divergence. Le calcul s'arrête bien au premier jacobien négatif mais il fait quand même une sortie de résultat pour l'incrément divergé. En conséquence, on se retrouve avec un résultat à l'incrément où il y a eu un jacobien négatif (par exemple : voir EPS11 dans Gmsh au dernier incrément => valeurs très grandes de l'ordre de 1e+141)
Pour être précis, le calcul joint à ce ticket diverge à l'incrément 17 (temps = 0.136). Donc, normalement, il ne devrait pas y avoir de sortie de résultat pour cet incrément. Mais j'ai constaté également une erreur de temps associée à ça.
En fait, j'ai constaté 2 cas :
- si je mets :
para_pilotage_equi_global
TYPE_DE_PILOTAGE AUCUN_PILOTAGE
=> sortie Gmsh et maple pour l'incrément 17 divergé + erreur sur le temps (le temps associé au dernier incrément est 0.144 au lieu 0.136)
- si je ne mets en commentaire :
para_pilotage_equi_global
##TYPE_DE_PILOTAGE AUCUN_PILOTAGE
donc par défaut, ça vaut PILOTAGE_BASIQUE.
=> idem mais pas d'erreur sur le temps (dernier incrément avec t = 0.136 dans le .maple et fichiers Gmsh)