Projet

Général

Profil

Anomalie #124

Non régression entre v7.771 et v7.772-4 (intro les_Fonctions_nD)

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

Statut:
Résolu
Priorité:
Haut
Assigné à:
Version cible:
-
Début:
24/10/2016
Echéance:
% réalisé:

100%

Temps estimé:
Temps passé:

Description

Gérard,

Sur un modèle BSO, le calcul converge avec la version 7.771 mais il diverge avec les versions supérieures (jacobien nul ou inf). Les premières 500 itérations sont identiques (même fichier log) et il y a divergence brutale après.

La version 772 et suivantes apportent les fonction nD !!! Elles ne sont donc pas utilisables pour moi ce qui est bien dommage...


Fichiers

BSOmher.7z (16,3 ko) BSOmher.7z Frank Petitjean, 24/10/2016 09:20
lois_materiaux (820 octets) lois_materiaux Frank Petitjean, 24/10/2016 09:25
plan.her (2,53 ko) plan.her Frank Petitjean, 24/10/2016 14:12
9-BSOmher.zip (26,2 ko) 9-BSOmher.zip Frank Petitjean, 27/10/2016 15:07
BSO.7z (4,79 ko) BSO.7z Frank Petitjean, 11/11/2016 09:18
#1

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

Ajout fichier matériaux

#2

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

Bonjour Frank,
en fait, l'ensemble des tests est ok entre les versions 7.771 et supérieurs. Mais effectivement il y a sans doute des points qui n'ont pas été testés. Il faudrait mettre ton calcul sous forme d'un test (sous forme minimaliste pour qu'il soit rapide) ce qui permettrait de vérifier la compatibilité avec les nouvelles versions.

#3

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

#4

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

  • Statut changé de Nouveau à En cours
  • % réalisé changé de 0 à 20

Frank,
j'ai essayé d'analyser le problème et j'ai quelques conclusions.
1) il y a bien eu une modification dans la loi critère qui peut expliquer que les résultats soient différents avec la version actuelle. Cependant, il s'agit bien d'une amélioration et non d'un bug (a priori). Du coup, les résultats divergents que l'on observe ici montrent sans doute que la méthodologie globale n'est pas assez robuste.
2) En examinant les messages d'erreur et en debug, j'ai pu constater qu'il y avait à partir d'un certain moment une énorme variation d'épaisseur. Je pense que c'est du à l'algorithme de Newton qui applique la contrainte de sig33 = 0. Ce n'est même pas au niveau des plis. Une explication est le fait que la cinématique appliquée au travers de l'algo de relaxation dynamique, introduit de fortes oscillations locales de déformations qui mettent certaine fois en défaut l'algo de Newton.
Je pense (mais à vérifier) que l'amortissement visqueux serait moins impactant à ce niveau.
Ceci étant, une solution pour l'amortissement cinétique, que l'on a déjà évoquée est d'avoir une loi de base sans algo de newton interne, qui soit utilisée jusqu'à une certaine stabilité de la structure et seulement ensuite l'introduction de la loi finale.

Une solution lourde et pas pratique, serait de stabiliser la géométrie avec une première loi. Sauvegarder la forme. Repartir de la forme avec la loi définitive.
-> à mon avis ce n'est pas la bonne voie.

Une autre solution serait d'utiliser une loi des mélanges, pondérée par la précision actuelle sur le résidu, qui permettrait d'entrer deux lois, la première simple, la seconde de plis. Au début du calcul, c'est la première loi qui est utilisée et lorsque la précision est suffisante, on bascule sur la seconde loi.
Un premier intérêt est qu'avec la loi des mélanges on peut spécifier que tant que la pondération sur la seconde loi = 0, la seconde loi n'est pas activée. Du coup le calcul n'utilise en fait qu'une seule loi ce qui permet de garantir une rapidité.

Un second intérêt est que cette technique peut se dérouler dans un même incrément de manière automatique. De plus, ceci peut-être vrai sur plusieurs incréments...

bon... mais actuellement la pondération disponible sur la loi des mélanges, n'intègre pas les variables globales ... donc il faut que j'introduise cela dans le code.

Je pense que c'est la bonne solution. J'espère pouvoir mettre cela en place rapidement (mais en dehors des vacances !).

à suivre ...

#5

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

J'ai une 2e situation de non régression entre ces 2 version de Herezh qui me parait plus suspecte. Le cas joint (que j'espère complet !) comporte 2 incréments de calcul, il s'agit du problème d'équilibre du BSO. Il converge rapidement (< 14min) avec la version 7.771, c'est donc déjà un petit succès !
Avec la version > 7.771 le premier incrément de charge donne des résultats identiques (exactement même fichier log). Par contre il diverge à la première itération de l'incrément 2.
Est-ce lié au calcul de la masse en début d'incrément ?
Merci

Frank

#6

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

Gérard,

J'ai un cas plus simple (3 fichiers et quelques dizaines de secondes de calcul) qui met en évidence ce problème de divergence qui apparait à partir de la version 7.772. La divergence intervient systématiquement au 2e incrément même si il ne se passe rien !

Ce problème assez handicapant car je ne peux pas bénéficier des toutes les évolutions que tu a apportées à Herezh depuis et celles à venir, et je ne vois pas comment le contourner...

Merci

#7

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

Frank,
effectivement ce cas diverge directement au deuxième incrément.
Par contre si tu fais un incrément puis sauvegarde, puis restart, => tout semble bien se présenter.
cependant je continue à regarder et je pense avoir une idée.
@+

#8

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

  • Statut changé de En cours à Résolu
  • % réalisé changé de 20 à 100

Frank,
une initialisation mal placée à un changement d'incrément !!
Sur ton dernier test c'est ok. Je mets la nouvelle version 6.782, dans la partie test, car je n'ai pas eu le temps de passer tous les tests de validation.
J'espère que c'est ok,
@+

#9

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

Merci Gérard, j'avais justement fini une première version des mes modules Python que je dois transmettre à Walter pour l'intégration dans Omher. Je test de suite cette nouvelle version !

#10

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

Après essai la version 6.782 se comporte comme la précédente et j'ai une divergence au 2e incrément !
As-tu bien appliqué la correction ?

#11

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

oui, la version compilée avec les mêmes sources se comporte différemment sur mac et sur linux. Je pense que les dépendances sur linux ont dû avoir un pb de mise à jour. Du coup je vais être obligé de recompiler toutes les sources sur linux ce qui va me prendre un petit moment !!
bon... par contre cela fonctionne sur mac, donc on peut imaginer que ce n'est qu'un pb de compilation...
affaire à suivre

#12

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

La divergence observée était due a priori à une précision différente entre les deux os.
Néanmoins le problème de fond est que dans le cas de très grands déplacements (ce qui est le cas ici au moment du changement d'incrément, dû au fait du changement de CL par exemple) il y a non-convergence transitoirement de la loi CP et/ou CP2 à cause du Newton local. La loi de substitution via la technique de perturbation conduisait à une épaisseur et/ou largeur quasi nulle, et c'est cela qui introduisait le dysfonctionnement.
J'ai introduit des bornes de limitation de variation d'épaisseur et de largeur avec également la possibilité de changer ces bornes via les paramètres d'entrée, qui par défaut sont min:max = 0.001:1000 (maxi = 1000 fois l'épaisseur initiale).
Avec ces intervalles, le calcul n'est pas interrompu et ensuite il y a convergence)
J'ai testé la nouvelle version sous mac et sous linux sur ce test. Je mets sur le serveur la version 1.55 boost pour linux et les versions osX, dans la partie test.
En espérant que cette fois sera la bonne !
NB: pour l'instant seule la doc dans herezh indique comment utiliser ces bornes

#13

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

Gérard,
Je confirme le bon fonctionnement de la 6.783 sur Linux.
La "loi" CP2 n'en fini pas de nous donner du fil à retordre... Il n'empêche, c'était une excellente idée :-)
Merci au développeur !

Formats disponibles : Atom PDF

Redmine Appliance - Powered by TurnKey Linux