MFRONT: integration of material law fails

Johannes_ACKVA

Bonjour / Hello

using MFRONT the integration of material law fails. The attached .comm contains 2 analyses STAT_NON_LINE,

one with an MFRONT behaviour:

COMPORTEMENT=( . . . RELATION='MFRONT', NOM_ROUTINE='astersimomiehevmis', DEFORMATION='SIMO_MIEHE', . . .

)

the other with the exact corresponding Aster material behaviour:

COMPORTEMENT=( . . . RELATION='VMIS_ISOT_LINE', DEFORMATION='SIMO_MIEHE',), . . .

)

The latter converges without problems

Any idea what is the problem with the MFRONT model?

(I m not sure if the mixture of elements (0D, 1D, 2D) could cause the problem, but I suppose not)

(I can't deliver the mesh due to confidentiality)

Thank you

Johannes_ACKVA

---------------------------------------------------------------------------

CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

NEW: ONLINE- and video courses

Attached file:
01_forming_MFRONT_ToForum.zip, 29756kb

thomas.helfer

Hi Johannes,

Your behaviour does not compute the consistent tangent operator, so it can't work with code_aster. It's a shame that code_aster does not report MFront error currently, but you can display them by compiling your mfront using the --@AsterErrorReport=true option.

Please find attached another version which is part of a tutorial about FeFp plasticity that I have not finished nor published yet. I only tested it at the material point level, so don't hesitate to make feed-backs.

In pratice, you'd better use GDEF_LOG :) Results are undistinguishable in most cases.

Best,

Thomas

Attached file:
FeFp.zip, 443386kb

thomas.helfer

Also, you probably need to add two dummy variables as follows:

@MaterialProperty real dummy1, dummy2;

Johannes_ACKVA

hello Thomas

many thanks for your help. What I continued:

(1)

I tried with the logarithmic strain, employing both, the code-aster built-in-material law and mfront (Plasticity.mfront).

This is how the part in the STAT_NON_LINE command looks:

built-in:

COMPORTEMENT=( 
                                        _F(TOUT='OUI', RELATION='VMIS_ISOT_LINE', DEFORMATION='GDEF_LOG',),
                                        _F(GROUP_MA='springs', RELATION='ELAS', DEFORMATION='PETIT',),
	  	              	  	),

mfront:

COMPORTEMENT=(
                                         _F(
                                            GROUP_MA='notPointElm',  # group of all elms but not the spring point elements
                                            RELATION='MFRONT',
                                            NOM_ROUTINE='asterplasticity',UNITE_LIBRAIRIE=40,DEFORMATION='GDEF_LOG',
                                           ),
                                         _F(GROUP_MA='springs', RELATION='ELAS', DEFORMATION='PETIT',),
                                      ),

The results are in perfect accordance, the CPU time of the STAT_NON_LINE with mfront is slightly longer (

(2)

I tried with the SIMO_MIEHE strain, again with the code-aster built-in-material law and mfront material.

I employed the new FeFpImplicitPlasticity.mfront which you attached in your post:

COMPORTEMENT=( 
                                        _F(TOUT='OUI', RELATION='VMIS_ISOT_LINE', DEFORMATION='SIMO_MIEHE',),
                                        _F(GROUP_MA='springs', RELATION='ELAS', DEFORMATION='PETIT',),
	  	              	  	),

and

COMPORTEMENT=(
                                         _F(
                                            GROUP_MA='notPointElm',
                                            RELATION='MFRONT',
                                            NOM_ROUTINE='asterImplicitFeFpPlasticity',UNITE_LIBRAIRIE=41,DEFORMATION='SIMO_MIEHE',
                                           ),
                                         _F(GROUP_MA='springs', RELATION='ELAS', DEFORMATION='PETIT',),
                                      ),

The run with the built-in material is successful. There are slight differences to the results with GDEF_LOG strain

The run with FeFpImplicitPlasticity.mfront stops early at command CREA_LIB_MFRONT:

# ------------------------------------------------------------------------------------------ # Commande No : 0002 Concept de type : - # ------------------------------------------------------------------------------------------ CREA_LIB_MFRONT(UNITE_MFRONT=39, UNITE_LIBRAIRIE=41, DEBUG='NON',) !--------------------------------------------------------------------------------! ! <EXCEPTION> <MFRONT_4> ! ! ! ! Le fichier de sortie de MFront libAsterBehaviour.so n'a pas pu être produit. ! ! ! ! Conseil : Vérifiez l'existence du fichier fourni au mot-clé UNITE_MFRONT. ! !--------------------------------------------------------------------------------!

<S> ERREUR UTILISATEUR RECUPEREE PAR LE SUPERVISEUR

(2a)

I tried to compile FeFpImplicitPlasticity.mfront with a mfront standalone. This problem appears:

johannes@nero:~/Work/22_DELEM/01_forming_MFRONT_SIMO_MIEHE$ /opt/tfel/tfel-3.2.1.build-on-florida1804/bin/mfront --obuild --interface=aster FeFpImplicitPlasticity.mfront Error while treating file 'FeFpImplicitPlasticity.mfront' BehaviourDSLBase:: error while treating keyword '@UseQt' at line '5' of file 'FeFpImplicitPlasticity.mfront'.

The keyword: '@UseQt' has been disabled

Any suggestions?

Best regards

Johannes_ACKVA

*** NEW: all Code-Aster courses now as Video and Webinar courses ***

thomas.helfer

Hi Johannes,

I forgot that code_aster uses such an outdated version of mfront (3.2.1 is at least four years old now).

Unfortunately, the file that I sent you only works for tfel >= 4.0.x .

Sorry, I did not take care of that. If you need it, you must recompile a version of aster with this version...

Best,

Thomas

Johannes_ACKVA

"""

but you can display them by compiling your mfront using the --@AsterErrorReport=true option.

"""

I do not understand. What must I do? Include the line "@AsterErrorReport=true" in the mfront-file?,?

Johannes_ACKVA

*** NEW: all Code-Aster courses now as Video and Webinar courses ***

thomas.helfer

When compiling your mfront file, as follows:

$ mfront --obuild --interface=aster --@AsterErrorReport=true .mfront

Johannes_ACKVA

thanky ou Thomas!

I did not follow your last step (did not install a newer mfront),

but have another question:

** how can the material internal variables be recognized ?

Example: Placticity.mfront:

LOGMF=STAT_NON_LINE(. .


                  COMPORTEMENT  =_F(RELATION='MFRONT',
                                    NOM_ROUTINE='asterplasticity', LIBRAIRIE='src/libAsterBehaviour.so',
                                    DEFORMATION='GDEF_LOG',
                    . . .

),

in .mess I get

Liste des comportements


   Affecté sur 2 éléments
     Relation                             : prototype (MFRONT ou UMAT)
     Déformation                          : GDEF_LOG
     Nombre total de variables internes   : 13

Pour les comportements externes prototypes (MFRONT ou UMAT), on n'a pas d'informations sur le nom des variables internes.

so I can't know the internal variables

When I run Code-Aster with the corresponding built-in material:

STAT_NON_LINE(... COMPORTEMENT=_F(RELATION='VMIS_ISOT_LINE', DEFORMATION='GDEF_LOG',...),


..
   Liste des comportements
   Affecté sur 2 éléments
     Relation                             : VMIS_ISOT_LINE
     Déformation                          : GDEF_LOG
     Nombre total de variables internes   : 8
            V1 : EPSPEQ
            V2 : INDIPLAS
            V3 : TXX
            V4 : TYY
            V5 : TZZ
            V6 : TXY
            V7 : TXZ

V8 : TYZ

then I find (printing the results to .resu) that V7 of the mfront material is identic with V1 of the built-in material, thus EPSPEQ

It should be recognizable anywhere, from Placticity.mfront?

but how? and 13 variables?

thank you again and best regards

Johannes_ACKVA

*** NEW: all Code-Aster courses now as Video and Webinar courses ***

thomas.helfer

Hi Johannes,

code_aster can retrieve this information from the shared library directly, as well as the names of the internal state variables, although it is sadly currently not exploited.

But you can use mtest in python (and in your .comm file) as follows:

```python

import mtest

b = mtest.Behaviour("aster", "src/libAsterBehaviour.so",

"asterplasticity", "Tridimensional")

print(b.expandInternalStateVariablesNames())

```