Welcome to the forums. Please post in English or French.

You are not logged in.

#1 2022-06-21 17:13:14

Johannes_ACKVA
Member
From: Ingenieurbüro für Mechanik, DE
Registered: 2009-11-04
Posts: 761
Website

MFRONT: integration of material law fails

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

Last edited by Johannes_ACKVA (2022-06-21 17:15:14)


Attachments:
01_forming_MFRONT_ToForum.zip, Size: 29.06 KiB, Downloads: 40

Ingenieurbüro für Mechanik
D 91717 Wassertrüdingen / Germany

www.code-aster.de                                                Training & Support for NASTRAN and CODE-ASTER

Offline

#2 2022-06-23 08:04:03

thomas.helfer
Member
Registered: 2013-09-26
Posts: 127

Re: MFRONT: integration of material law fails

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 smile Results are undistinguishable in most cases.

Best,

Thomas


Attachments:
FeFp.zip, Size: 432.99 KiB, Downloads: 52

Offline

#3 2022-06-23 08:07:08

thomas.helfer
Member
Registered: 2013-09-26
Posts: 127

Re: MFRONT: integration of material law fails

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

@MaterialProperty real dummy1, dummy2;

Offline

#4 2022-06-23 18:36:06

Johannes_ACKVA
Member
From: Ingenieurbüro für Mechanik, DE
Registered: 2009-11-04
Posts: 761
Website

Re: MFRONT: integration of material law fails

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 (<< 1 pct) than of the STAT_NON_LINE with the built-in material law

(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::analyse: 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  ***


Ingenieurbüro für Mechanik
D 91717 Wassertrüdingen / Germany

www.code-aster.de                                                Training & Support for NASTRAN and CODE-ASTER

Offline

#5 2022-06-23 18:51:41

thomas.helfer
Member
Registered: 2013-09-26
Posts: 127

Re: MFRONT: integration of material law fails

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

Offline

#6 2022-06-23 19:04:21

Johannes_ACKVA
Member
From: Ingenieurbüro für Mechanik, DE
Registered: 2009-11-04
Posts: 761
Website

Re: MFRONT: integration of material law fails

"""
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  ***


Ingenieurbüro für Mechanik
D 91717 Wassertrüdingen / Germany

www.code-aster.de                                                Training & Support for NASTRAN and CODE-ASTER

Offline

#7 2022-06-23 19:06:11

thomas.helfer
Member
Registered: 2013-09-26
Posts: 127

Re: MFRONT: integration of material law fails

When compiling your mfront file, as follows:

$ mfront --obuild --interface=aster --@AsterErrorReport=true <your_file>.mfront

Offline

#8 2022-06-27 16:32:26

Johannes_ACKVA
Member
From: Ingenieurbüro für Mechanik, DE
Registered: 2009-11-04
Posts: 761
Website

Re: MFRONT: integration of material law fails

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  ***


Ingenieurbüro für Mechanik
D 91717 Wassertrüdingen / Germany

www.code-aster.de                                                Training & Support for NASTRAN and CODE-ASTER

Offline

#9 2022-06-27 17:04:12

thomas.helfer
Member
Registered: 2013-09-26
Posts: 127

Re: MFRONT: integration of material law fails

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())
```

Offline