Problème de convergence en Hyperelastic

Groguiguy · 2017-12-13 16:58:03

Bonjour à tous,

Ci-dessous vous pouvez voir mon fichier .comm pour un cas d'une géométrie complexe en déplacement imposée et matériaux hyperélastique.
Cependant, si le cas tourne parfaitement en élasticité linéaire, impossible de faire converger la solution en STAT_NON_LINE malgré la lecture assidu de la document relative aux Solveurs et au à la STAT_NON_LINE.

J'en viens à supposer que mon problème non-linéaire est mal posé, par exemple par un mauvais emploi des l’incrémentation en pas de temps.

Voici le "message" généré à la suite du calcul :

*SNIP*(supprimé pour faciliter la lecture)

Pourquoi ce message " Sur certaines mailles, la modélisation est incompatible avec le comportement. Une erreur fatale pourrait suivre se message." apparaît il?

J'ai l'impression d'avoir tout essayé au niveau du solveur et des réglages de STAT_NON_LINE, j'en conclu que cela vient peut être des pas de temps?

Qu'en pensez vous? Code_aster est il robuste en hyperélasticité? Est un problème du à la matrice tangente?

En vous remerciant par avance.
Guillaume

Last edited by Groguiguy (2017-12-15 13:58:52)

Groguiguy · 2017-12-14 10:53:58

Du coup, j'ai évidemment testé les réglages avec un cube en traction : cube de 200mm de coté, encastré d'un coté, avec déplacement imposé de 10mm de l'autre coté. Matériaux hyperélastique : C10 = 0.1 et K = 10000000.

Voici le "message" :

*SNIP*(supprimé pour faciliter la lecture)

Bref, là aussi je n'arrive pas à faire converger le problème pourtant très simple. Qu'avez vous à me conseiller au niveau des réglages de pas de temps ou de solveur?
Y a t'il des tuto adaptés? Je suppose que oui, mais je n'ai rien trouvé!

Merci d'avance!

Last edited by Groguiguy (2017-12-15 13:59:26)

jeanpierreaubry · 2017-12-14 11:59:04

bonjour

et avec un critère de convergence un peu moins fin que 1e-6

jean pierre aubry

Groguiguy · 2017-12-14 16:55:32

et avec un critère de convergence un peu moins fin que 1e-6

Effectivement, mais j'aimerai quantifier ce RESI_GLOB_RELA ou RESI_GLOB_MAXI.
Comme je n'ai pas voulu toucher à la valeur de l'un ou de l'autre vu que c'est déconseillé, je vais peut être me tourner vers RESI_COMP_RELA et RESI_REFE_RELA.

jeanpierreaubry · 2017-12-14 17:13:36

Comme je n'ai pas voulu toucher à la valeur de l'un ou de l'autre vu que c'est déconseillé

je crois qu'il ne faut pas avoir peur d'expérimenter dans ce domaine
il m'est arrivé de faire

	CONVERGENCE=_F(
		RESI_GLOB_RELA=1.E-3,
                .............

avec des résultats convenables

Groguiguy · 2017-12-14 18:39:36

Merci Jean-Pierre, c'est effectivement ce que je viens de faire, en comparant à mes résultats analytiques, et c'est effectivement très proche.

J'ai tout de même l'impression que Code_Aster n'est pas très robuste pour de l'hyperélasticité, en tout cas en laissant un résidu faible (e-5 par exemple) et lorsque la déformation devient importante (de l'ordre de 25%), ou nécessite d'adapter les réglages de STAT_NON_LINE pour chaque cas, ce qui peut ne pas convenir à notre objectif d'automatisation.
Il y a notamment les critères de réglages de la matrice tangente qui ont l'air développé pour de l’élasticité, pas de hyperélasticité puisqu'ils demandent le mot-clé "MATRICE='Elastique'" où le code vérifie l'existence d'un module d'Young dans "MATERIAUX" pour les premiers pas de temps. Il me semble d'ailleurs que la résolution des équations se fait toujours en HPP.

J'ai vu sur ce forum que AlexD avait voulu participé au développement de l'hyperélasticité dans Code_Aster car justement (en 2008 année du post) ça n'était pas du tout la priorité de EDF. Avez vous un nouveau son de cloche dorénavant? Y a t'il des utilisateurs de Code_Aster en grandes déformations?

jeanpierreaubry · 2017-12-14 18:49:20

Y a t'il des utilisateurs de Code_Aster en grandes déformations?

en tout cas pas moi !!
je n'ai jamais eut à traiter ce genre de problème

mon exemple de RESI_GLOB_RELA=1.E-3 qui est une valeur relativement élevée vient d'une analyse de dynamique rapide avec DYNA_NON_LINE et 31 contacts indépendants sur du caoutchouc mais élastique

pour STAT_NON_LINE j'essaye d'être moins extrême !

Last edited by jeanpierreaubry (2017-12-15 10:55:59)

Groguiguy · 2017-12-15 10:38:33

Au laboratoire nous travaillons sur la modélisation d'organes humains mous, soumis à différents efforts. Nous modélisions l'ensemble de nos problèmes sur Abaqus sans problème, mais je suis en charge de trouver un moyen de réaliser ces modélisations sur logiciel libre.
Nos modélisations atteignent souvent 20% de déformation, donc nous utilisons des lois hyperélastiques bien sur.
De plus, comme nous utilisons des géométries issues d'IRM, elles ne sont jamais simplifiables par symétrie. On cherche donc des moyens de diminuer les coûts de calculs : par exemple pour simuler l'impact des ligaments nous souhaitions tester l'emploi d'éléments câbles (rapport à mon précédent sujet) sans en faire une représentation géométrique.

Mais là, de ce que je vois sur Code_Aster, atteindre 10% de déformation est déjà délicat, à 20% je suis obligé d'augmenter le résidu à 1e-2... pour un simple cube en traction.
Du coup je me demande s'il n'est pas préférable d'abandonner Code_Aster et repartir sur Calculix (où nous avions des résultats), ou alors se limiter à des lois élastiques et approximer les valeurs des tissus mous à 10-20% de déformation. Mais si je comprends bien la doc, Code_Aster réalise tous ses calculs avec Hypothèse des Petites Perturbations. Si c'est le cas, pas étonnant qu'il ne converge pas sur les grandes déformations.

Last edited by Groguiguy (2017-12-15 10:50:11)

Groguiguy · 2017-12-15 13:57:32

En fait je viens de remarquer que le problème de non-convergence apparait toujours au premier pas de temps, au moment où RESI_GLOB_RELA ne peut pas être pris en compte et c'est RESI_GLOB_MAXI qui l'est comme le mentionne la doc u4.51.03 :

Lorsque le chargement et les réactions d'appui deviennent nuls, c'est-à-dire lorsque L est nul (par exemple dans le cas d'une décharge totale), on essaie de passer du critère de convergence relatif RESI_GLOB_RELA au critère de convergence absolu RESI_GLOB_MAXI. Cette opération est transparente pour l'utilisateur (message d'alarme émis dans le fichier .mess). Lorsque le vecteur L redevient différent de zéro, on repasse automatiquement au critère de convergence relatif RESI_GLOB_RELA.
Toutefois, ce mécanisme de basculement ne peut pas fonctionner au premier pas de temps. En effet, pour trouver une valeur de RESI_GLOB_MAXI raisonnable de manière automatique (puisque l'utilisateur ne l'a pas renseigné), on a besoin d'avoir eu au moins un pas convergé sur un mode RESI_GLOB_RELA. Dès lors, si le chargement est nul dès le premier instant, le calcul s'arrête.
L'utilisateur doit déjà alors vérifier que le chargement nul est normal du point de vue de la modélisation qu'il réalise, et si tel est le cas, trouver un autre critère de convergence (RESI_GLOB_MAXI par exemple).

Du coup, connaissez vous un moyen pour fiabiliser le calcul au premier pas?
1) Augmenter le résidu Max? Mais ça n'est absolument pas fiable car l'erreur peut se propager par la suite.
2) Imposer une tangente au départ? Mais comment faire?
3) Discrétiser d'avantage le pas de calcul? Mais je suis déjà au maximum il me semble.
4) Mettre un "amortissement" numérique sur le Newton-Raphson?Mais comment faire?

NB : il est à noter que mettre une force nulle fait également diverger le système bien sur, puisqu'on est alors dans le cas énoncé ci-dessus de relaxation totale.

Last edited by Groguiguy (2017-12-15 14:00:11)

AsterO'dactyle · 2017-12-15 21:02:58

Bonjour,

Difficile de dire quoique ce soit sans fichier de commandes, ni maillage

Néanmoins, faites attention au choix de l'élément. Quel type utilisez-vous ?

Attention aussi au choix de K, préférez NU=0.499.

On a déjà fait des calculs en hyper-élasticité avec des grandes déformations (plus de 100%) sans rencontrer de difficultés particulières.
Relacher RESi_GLOB_RELA n'est pas une bonne idée en général.

Groguiguy · 2017-12-18 15:04:46

Voici mon fichier de commande (je dois demander l'autorisation pour partager le maillage) :

DEBUT(RESERVE_CPU = _F(BORNE = 600,),)
mesh = LIRE_MAILLAGE(FORMAT='MED', UNITE=20, INFO_MED=2)
model = AFFE_MODELE(
AFFE=_F(MODELISATION=('3D', ), PHENOMENE='MECANIQUE', TOUT='OUI'),
MAILLAGE=mesh)
mater = DEFI_MATERIAU(ELAS_HYPER=_F(C01=0, C10=1000, K=10000000.0))
fieldmat = AFFE_MATERIAU(AFFE=_F(MATER=(mater, ), TOUT='OUI'), MODELE=model)
times = DEFI_LIST_INST(DEFI_LIST=_F(VALE=(0.0,0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1.0)),
METHODE='AUTO',
ECHEC=_F(EVENEMENT='ERREUR',
ACTION='DECOUPE'),
ADAPTATION=_F(EVENEMENT='SEUIL',
NOM_PARA='NB_ITER_NEWTON',
NB_INCR_SEUIL=2))
Encastr = AFFE_CHAR_MECA(
FACE_IMPO=_F(
DX=0.0,
DY=0.0,
DZ=0.0,
GROUP_MA=('Group_1', 'Group_2', 'Group_3', 'Group_4','Group_7','Group_8')),
MODELE=model)

Pression = AFFE_CHAR_MECA(
PRES_REP=_F(
PRES=3000,
GROUP_MA=('Group_5','Group_6')),
MODELE=model)
resnonl = STAT_NON_LINE(CHAM_MATER=fieldmat,
MODELE=model,
EXCIT=(_F(CHARGE=Pression,
TYPE_CHARGE='FIXE_CSTE',),
_F(CHARGE=Encastr,
TYPE_CHARGE='FIXE_CSTE',),),
INCREMENT=_F(LIST_INST=times,
INST_INIT=0.1,
INST_FIN=1.0,
PRECISION=1.E-06,),
COMPORTEMENT=_F(DEFORMATION='GROT_GDEP',
RELATION='ELAS_HYPER',
TOUT='OUI',
ITER_INTE_MAXI=10,
RESI_INTE_RELA=1.E-06,
ITER_INTE_PAS=0,
RESI_CPLAN_RELA=1.E-06,
PARM_THETA=1.0,
SYME_MATR_TANG='OUI',
ITER_CPLAN_MAXI=1,
PARM_ALPHA=1.0,),
NEWTON=_F(REAC_INCR=1,
MATRICE='TANGENTE',
REAC_ITER=1,
MATR_RIGI_SYME='NON',
PAS_MINI_ELAS=0,
REAC_ITER_ELAS=0,
),
CONVERGENCE=_F(ARRET='OUI',
ITER_GLOB_MAXI=10,
RESI_GLOB_RELA=1e-2,
RESI_GLOB_MAXI=1e-2,
ITER_GLOB_ELAS=100,
),
SOLVEUR=_F(RENUM='METIS',
STOP_SINGULIER='OUI',
ELIM_LAGR='NON',
NPREC=8,
METHODE='MUMPS',
),
METHODE='NEWTON',
ARCHIVAGE=_F(PRECISION=1.E-06,
CRITERE='RELATIF',),
MESURE=_F(TABLE='NON',), )
IMPR_RESU(FORMAT='RESULTAT', RESU=_F(MAILLAGE=mesh,RESULTAT=resnonl), UNITE=10)
FIN()

Même avec un résidu comme celui-ci, le calcul ne converge pas. Le RESI_GLOB_RELA étant de l'ordre de 1e3 et le RESI_GLOB_MAXI de l'ordre de 1e2 voir plus.
Décomposer le pas de temps est inutile, car même après décomposition le calcul est exactement le même : mêmes valeurs de résidu.

En ce qui concerne la qualité de maillage, le plus mauvais éléments a un rapport de forme 3D de 12,5 et 2D de 6.5, mais 95% de l'histogramme se situe entre [1;4] en 3D et [1;1.3] en 2D.
Nous utilisons des éléments tétrahédriques du second ordre de 3mm en taille maximale, pour 85000 éléments 3D, 24000 2D et 1100 1D généré par NetGen.
A terme nous souhaitons utiliser 4 matériaux différents sur le même modèle : 3 Yeoh, et 1 incompressible sans propriété de cisaillement (comme de l'eau dans une bouteille en somme).

Avez vous des conseilles pour nous aider à utiliser Code_Aster en mécanique des corps mous? Ou sur notre modélisation? J'espère avoir rapidement l'autorisation de vous faire partager le maillage.

Volker · 2017-12-18 17:09:21

Have you ramped up your pressure from zero to PRES=3000?

I think, you want to compute a jump:
resnonl = STAT_NON_LINE(CHAM_MATER=fieldmat,
MODELE=model,
EXCIT=(_F(CHARGE=Pression,
TYPE_CHARGE='FIXE_CSTE',),
_F(CHARGE=Encastr,
TYPE_CHARGE='FIXE_CSTE',),),
but this will not work... unfortunatelly..!!

Groguiguy · 2017-12-18 17:42:15

I understand. Perhaps you're right, I didn't try it.
I might set pressure with a ramp, I will try it. I must find how to do that.

Volker · 2017-12-18 20:40:08

here is an example:

CHAR_fix=AFFE_CHAR_MECA(MODELE=MODE,
                        DDL_IMPO=(_F(GROUP_MA='DY',
                                     DY=0.0,),
:
:
CHAR_los=AFFE_CHAR_MECA(MODELE=MODE,
                        FORCE_FACE=_F(GROUP_MA='Kraft',
                                      FZ=60.0,),);

Liste=DEFI_LIST_REEL(DEBUT=0.0,
                     INTERVALLE=_F(JUSQU_A=1.0,
                                   PAS=0.1,),
                     INFO=2,);

Lst_Auto=DEFI_LIST_INST(DEFI_LIST=_F(METHODE='AUTO',
                                     LIST_INST=Liste,
                                     PAS_MINI=0.0001,),
:
# Function will ramp up FORCE_FACE in CHAR_los from 0 % (at inst=0) to 100 % load (at inst = 1)
Function=DEFI_FONCTION(
                       NOM_PARA='INST',
                       VALE=(0.0 ,0.0 ,
                             1.0 ,1.0 ,),
                       INFO=2,);

RESU=STAT_NON_LINE(MODELE=MODE,
                   CHAM_MATER=MATE,
                   EXCIT=(_F(CHARGE=CHAR_fix,),
                          _F(CHARGE=CHAR_los, FONC_MULT=Function,),),
:

greetings
Volker

Groguiguy · 2017-12-19 10:38:09

Thanks Volker,

I will try this way.

Groguiguy · 2017-12-20 17:48:14

Apparemment j'ai un problème de mouvement de corps rigide que je n'explique pas du tout.
J'ai changé la manière de définir le chargement en mettant les 3 types de chargement dans un "load" (voir ci-dessous).
Y a t'il une différence entre les deux écritures ci-dessous (dont une est en commentaire)?

DEBUT(RESERVE_CPU = _F(BORNE = 600,),)
mesh = LIRE_MAILLAGE(FORMAT='MED', UNITE=20, INFO_MED=2)
model = AFFE_MODELE(
AFFE=_F(MODELISATION=('3D', ), PHENOMENE='MECANIQUE', TOUT='OUI'),
MAILLAGE=mesh)
mater = DEFI_MATERIAU(ELAS_HYPER=_F(C01=0, C10=10000, K=10000000.0))
mater2 = DEFI_MATERIAU(ELAS=_F(E=1, NU=0.49))
fieldmat = AFFE_MATERIAU(MAILLAGE=mesh,
AFFE=(_F(GROUP_MA=('Vessie','Vagin','Rectum'),MATER=mater),
_F(GROUP_MA=('Graisse','Urine','Selles'),MATER=mater2))),
times = DEFI_LIST_INST(DEFI_LIST=_F(VALE=(0.0,0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1.0)),
METHODE='AUTO',
ECHEC=_F(EVENEMENT='ERREUR',
ACTION='DECOUPE'),
ADAPTATION=_F(EVENEMENT='SEUIL',
NOM_PARA='NB_ITER_NEWTON',
NB_INCR_SEUIL=2))
#Encastr1 = AFFE_CHAR_MECA(
# ARETE_IMPO=_F(
# DX=0.0,
# DY=0.0,
# DZ=0.0,
# GROUP_MA=('Group_9', 'Group_10', 'Group_11', 'Group_12')),
# MODELE=model)
#
#Encastr2 = AFFE_CHAR_MECA(
# FACE_IMPO=_F(
# DX=0.0,
# DY=0.0,
# DZ=0.0,
# GROUP_MA=('Group_7','Group_8')),
# MODELE=model)
#
#Pression = AFFE_CHAR_MECA(
# PRES_REP=_F(
# PRES=1000,
# GROUP_MA=('Group_5','Group_6')),
# MODELE=model)

load = AFFE_CHAR_MECA(
ARETE_IMPO=_F(
DX=0.0,
DY=0.0,
DZ=0.0,
GROUP_MA=('Group_9', 'Group_10', 'Group_11', 'Group_12')
),
FACE_IMPO=_F(
DX=0.0,
DY=0.0,
DZ=0.0,
GROUP_MA=('Group_7','Group_8')
),
MODELE=model,
PRES_REP=_F(
GROUP_MA=('Group_5', 'Group_6'),
PRES=1000
)
)
resnonl = STAT_NON_LINE(CHAM_MATER=fieldmat,
MODELE=model,
EXCIT=(_F(CHARGE=load,
TYPE_CHARGE='FIXE_CSTE',),),
INCREMENT=_F(LIST_INST=times,
INST_INIT=0.1,
INST_FIN=1.0,
PRECISION=1.E-06,),
COMPORTEMENT=(_F(DEFORMATION='GROT_GDEP',
RELATION='ELAS_HYPER',
GROUP_MA=('Vessie','Vagin','Rectum'),
ITER_INTE_MAXI=10,
RESI_INTE_RELA=1.E-06,
ITER_INTE_PAS=0,
RESI_CPLAN_RELA=1.E-06,
PARM_THETA=1.0,
SYME_MATR_TANG='OUI',
ITER_CPLAN_MAXI=1,
PARM_ALPHA=1.0,),
_F(DEFORMATION='GROT_GDEP',
RELATION='ELAS',
GROUP_MA=('Graisse','Urine','Selles'),
ITER_INTE_MAXI=10,
RESI_INTE_RELA=1.E-06,
ITER_INTE_PAS=0,
RESI_CPLAN_RELA=1.E-06,
PARM_THETA=1.0,
SYME_MATR_TANG='OUI',
ITER_CPLAN_MAXI=1,
PARM_ALPHA=1.0,)),
NEWTON=_F(REAC_INCR=1,
MATRICE='TANGENTE',
REAC_ITER=1,
MATR_RIGI_SYME='NON',
PAS_MINI_ELAS=0,
REAC_ITER_ELAS=0,
),
CONVERGENCE=_F(ARRET='OUI',
ITER_GLOB_MAXI=10,
RESI_GLOB_RELA=1e-2,
RESI_GLOB_MAXI=1e-2,
ITER_GLOB_ELAS=100,
),
SOLVEUR=_F(RENUM='METIS',
STOP_SINGULIER='OUI',
ELIM_LAGR='NON',
NPREC=8,
METHODE='MUMPS',
),
METHODE='NEWTON',
ARCHIVAGE=_F(PRECISION=1.E-06,
CRITERE='RELATIF',),
MESURE=_F(TABLE='NON',),),
IMPR_RESU(FORMAT='RESULTAT', RESU=_F(MAILLAGE=mesh,RESULTAT=resnonl), UNITE=10)
FIN()

Avant quelques modifications (ajout de matériaux et changement d'encastrement), le résidu était entre 1e2 et 1e30!
Maintenant avec le fichier .comm ci-dessus, le résidu ne s'affiche pas et ce message d'erreur apparait :

Instant de calcul: 1.500000000000e-01
---------------------------------------------------------------------
| NEWTON | RESIDU | RESIDU | OPTION |
| ITERATION | RELATIF | ABSOLU | ASSEMBLAGE |
| | RESI_GLOB_RELA | RESI_GLOB_MAXI | |
---------------------------------------------------------------------
Degré de liberté physique associé au noeud N22 et à la composante DX.
Problème : la matrice est singulière ou presque singulière :
Lors de la factorisation de la matrice, on a rencontré un problème
(pivot nul ou presque nul) à la ligne 64 qui correspond au degré de liberté donné ci-dessus.
Risques et conseils :
* Si la ligne correspond a un degré de liberté physique, il s'agit probablement d'un mouvement
de corps rigide mal bloqué.
Vérifiez les conditions aux limites.
Si vous faites du contact, il ne faut pas que la structure ne "tienne" que par le contact.
Vérifiez également les caractéristiques matériaux (module d'Young, ...).
* Si la ligne correspond a un degré de liberté de Lagrange, il s'agit sans doute d'une condition
limite redondante.
En particulier, il se peut que la relation linéaire surabondante provienne des conditions de contact.
Peut-être devriez vous exclure certains noeuds des conditions de contact
(mots clés SANS_NOEUD et SANS_GROUP_NO).
* Si le solveur utilisé est LDLT ou MULT_FRONT, vous pouvez utiliser le solveur MUMPS
car celui-ci est le seul à pouvoir factoriser les matrices qui ne sont pas définies positives.
* Parfois, en parallèle, le critère de détection de singularité de MUMPS est trop pessimiste ! Il reste néanmoins souvent
possible de faire passer le calcul complet en relaxant ce critère (augmenter de 1 ou 2 la valeur du mot-clé NPREC) ou
en le débranchant (valeur du mot-clé NPREC=-1) ou en relançant le calcul sur moins de processeurs.
* Il se peut aussi que ce phénomène soit tout à fait normal avec X-FEM si la fissure passe
très près d'un noeud.
Si le nombre de décimales perdues n'est pas trop grand (max 10 décimales),
vous pouvez relancer le calcul en augmentant le nombre de décimales perdues autorisé :
mot-clé NPREC du mot clé facteur SOLVEUR.
Sinon, contactez l'équipe de développement.
| 0 E | | |TANGENTE |
---------------------------------------------------------------------
<Erreur> La matrice du système est singulière
<Action> On essaie de découper le pas de temps.
On utilise la découpe manuelle.
Découpe uniforme à partir de l'instant < 1.000000000000e-01> en <4> pas de temps.
(soit un incrément constant de < 1.250000000000e-02>)
<Action> On découpe le pas de temps.
Temps CPU consommé dans ce pas de temps : 2 min 39 s
* Nombre d'itérations de Newton : 1
* Temps total intégration comportement : 5.779 s (1 intégrations)
* Temps total factorisation matrice : 2 min 31 s (1 factorisations)
* Temps construction second membre : 0.634 s
* Temps total résolution K.U=F : 0.000 s (0 résolutions)
* Temps assemblage matrice : 1.763 s
* Temps autres opérations : 0.007 s
Mémoire (Mo) : 21498.70 / 21149.43 / 1392.20 / 604.78 (VmPeak / VmSize / Optimum / Minimum)

Pourquoi le calcul ne donne t'il pas le résidu du premier pas?
J'ai peut être un problème dans la définition de mes conditions limites, qu'en pensez vous?

AsterO'dactyle · 2017-12-20 20:25:49

Bonjour,

C'est effectivement un problème de mouvement de corps rigide.
Vérifiez votre maillage, aster n'a-t-il pas détecté des noeuds double par exemple ?

Volker · 2017-12-21 09:10:34

Bonjour,
At first I thought your model is perhaps under constraint. The second theory is your material property C01. But my knowledge is very small regarding hyper elas. Can you explain me how is it possible that C01 is equal null?
I made a parameter fitting for a special seal rubber. I got for C01 approx. 150 and nu approx. 0.44 ???
Kind regards Volker

Groguiguy · 2017-12-21 11:07:29

J'ai trouvé, apparemment c'était un problème "d'unités" ou d'échelle entre mes grandeurs.

times = DEFI_LIST_INST(DEFI_LIST=_F(VALE=(0.0,0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1.0)),
METHODE='AUTO',
ECHEC=_F(EVENEMENT='ERREUR',
ACTION='DECOUPE'),
ADAPTATION=_F(EVENEMENT='SEUIL',
NOM_PARA='NB_ITER_NEWTON',
NB_INCR_SEUIL=2))
Liste=DEFI_LIST_REEL(DEBUT=0.0,
INTERVALLE=_F(JUSQU_A=1.0,
PAS=0.1,),
INFO=2,);
Lst_Auto=DEFI_LIST_INST(DEFI_LIST=_F(LIST_INST=Liste,
),),
Function=DEFI_FONCTION(
NOM_PARA='INST',
VALE=(0.0 ,0.0 ,
1.0 ,1.0 ,),
INFO=2,)
...
_F(CHARGE=Charg,FONC_MULT=Function,
TYPE_CHARGE='FIXE_CSTE',)
...

Avec "times" et "FONC_MULT=Function", comment sont gérés les incréments? Code_Aster fait les deux en même temps?

Groguiguy · 2017-12-22 09:57:48

"Arrêt par manque de temps CPU pendant les itérations de Newton au numéro d'instant < 26 >
- Temps moyen par itération de Newton : 158.182692
- Temps restant : 294.640544
La base globale est sauvegardée. Elle contient les pas archivés avant l'arrêt."
Je viens d'avoir cette erreur et je ne sais pas comment la corriger avec certitude car la doc que je trouve fait toujours référence à l'utilisation d'ASTK (que je n'utilise pas) ou j'ai trouvé cela :

Options:
-h, --help show this help message and exit
--commandes=FILE Code_Aster command file
--memjeveux=MEMJEVEUX maximum size of the memory taken by the execution (in Mw)
--memory=MEMORY maximum size of the memory taken by the execution (in MB)
--tpmax=TPMAX limit of the time of the execution (in seconds)
--max_base=MAXBASE limit of the size of the results database
--dbgjeveux turn on some additional checkings in the memory management
--num_job=JOBID job ID of the current execution
--mode=MODE execution mode (interactive or batch)
--interact as 'python -i' works, it allows to enter commands after the execution of the command file.
--rep_outils=DIR directory of Code_Aster tools (ex. $ASTER_ROOT/outils)
--rep_mat=DIR directory of materials properties
--rep_dex=DIR directory of external datas (geometrical datas or properties...)
--rep_glob=DIR directory of the results database
--rep_vola=DIR directory of the temporary database
--suivi_batch force to flush the output after each line
--totalview required to run Code_Aster through the Totalview debugger
--syntax only check the syntax of the command file is done

Faut il comprendre que "temps CPU" = tpmax?

De plus, qu'est ce que la base globale? Si cela signifie que Code_Aster a conservé en mémoire les itérations, peut on reprendre le calcul à cette itération? Si oui comment?

Merci

jeanpierreaubry · 2017-12-26 07:46:50

la bonne solution serait peut_être d'utiliser ASTK au moins une fois pour bien remplir toutes les données dans le fichier .export et comprendre ce que ce fichier doit contenir

Anirudh · 2017-12-27 12:57:48

Hi,
I am also interested in these problems, but no knowing how many iterations it would take before I get to this:
Non linear dynamics with buckling using hyperelastic material with self contact.

Regards
Anirudh

Attachments:
hyperelastic_rubber.gif, Size: 1.46 MiB, Downloads: 272

Volker · 2017-12-27 18:06:02

Bonjour Groguiguy,
two thoughts from me:
- first of all work with ASTK and install Grace.
- and secondly the smallest challenge is to compute an hyperelastic problem, an even bigger challenge is to dig out the correct material properties for C01 (in my opinion this parameter cant be zero), C10, C20 and my. As long as your material properties are not correct you are far away from reality.
For these purposes I attached a very early test case of parameter fitting of an hyperelastic seal material. This job can you run in ASTK and observe in Grace.

I hope you have fun and you come closer to the solution of your computing challenge.
Volker

Last edited by Volker (2017-12-27 18:08:19)

Attachments:
Forum_Hyper_Fit.tar.gz, Size: 9.11 KiB, Downloads: 371

Groguiguy · 2018-01-03 14:38:30

Merci à tous!

Currently I have no question because my model converge with good end results.

For this, I set tpmax=800000.0 and RESI_GLOB_RELA=1e-2. That's quite a lot, but that's good for my problem.

Volker, no problem to simulate with C01 = 0 like on Neo Hookeen model.

Groguiguy · 2019-01-17 13:59:45

Je me permet de remonter le sujet car j'ai toujours un problème avec le temps CPU (Arrêt pour manque de temps CPU).

Dans mon fichier export, je le défini comme suis :

P time_limit 11700.0
P tpsjob 19600

Où il me semble bien que c'est tpsjob qui défini la limite. Seulement, dès que je lance le calcul par le terminal linux, le fichier export est réécrit avec tpsjob 196 ce qui n'est pas suffisant. Comment faire pour augmenter le temps CPU du coup?

J'ai aussi défini cela dans le fichier .comm lié :

RESERVE_CPU=_F(BORNE=90000,)

Mais je sais pas si c'est suffisant.

#1 2017-12-13 16:58:03

Problème de convergence en Hyperelastic

#2 2017-12-14 10:53:58

Re: Problème de convergence en Hyperelastic

#3 2017-12-14 11:59:04

Re: Problème de convergence en Hyperelastic

#4 2017-12-14 16:55:32

Re: Problème de convergence en Hyperelastic

#5 2017-12-14 17:13:36

Re: Problème de convergence en Hyperelastic

#6 2017-12-14 18:39:36

Re: Problème de convergence en Hyperelastic

#7 2017-12-14 18:49:20

Re: Problème de convergence en Hyperelastic

#8 2017-12-15 10:38:33

Re: Problème de convergence en Hyperelastic

#9 2017-12-15 13:57:32

Re: Problème de convergence en Hyperelastic

#10 2017-12-15 21:02:58

Re: Problème de convergence en Hyperelastic

#11 2017-12-18 15:04:46

Re: Problème de convergence en Hyperelastic

#12 2017-12-18 17:09:21

Re: Problème de convergence en Hyperelastic

#13 2017-12-18 17:42:15

Re: Problème de convergence en Hyperelastic

#14 2017-12-18 20:40:08

Re: Problème de convergence en Hyperelastic

#15 2017-12-19 10:38:09

Re: Problème de convergence en Hyperelastic

#16 2017-12-20 17:48:14

Re: Problème de convergence en Hyperelastic

#17 2017-12-20 20:25:49

Re: Problème de convergence en Hyperelastic

#18 2017-12-21 09:10:34

Re: Problème de convergence en Hyperelastic

#19 2017-12-21 11:07:29

Re: Problème de convergence en Hyperelastic

#20 2017-12-22 09:57:48

Re: Problème de convergence en Hyperelastic

#21 2017-12-26 07:46:50

Re: Problème de convergence en Hyperelastic

#22 2017-12-27 12:57:48

Re: Problème de convergence en Hyperelastic

#23 2017-12-27 18:06:02

Re: Problème de convergence en Hyperelastic

#24 2018-01-03 14:38:30

Re: Problème de convergence en Hyperelastic

#25 2019-01-17 13:59:45

Re: Problème de convergence en Hyperelastic

Board footer