TFEL, MFront and MTestTFEL/Glossary libraryMFront
GenericBehaviourInterface:
rotateArrayOfTangentOperatorBlocks is not correctly
implementedautomakendarray.cxx sourceThe page describes the new functionalities of Version 3.4.1 of the
TFEL project.
This version notably adds:
MFront behaviours and support of this feature in the
generic interface. This version breaks the API
(Application Programming Interface) and ABI (Application
Binary Interface) of the generic interface. See Section
2.2.Cast3M 21. See Section 4.1.AMITEX_FFTP
solver.The following names are now reserved:
rho_m0 and ρₘ₀v_sound and vₛThose names can no longer be used to define MFront
variables.
See Section 4.4 for details.
generic interface`The data structures used by the generic interface,
namely mfront_gb_State, mfront_gb_InitialState
and mfront_gb_BehaviourData, has been changed to be able to
compute the speed of sound. This change breaks the API and
ABI of the behaviour generated by this interface. See also
Section 4.4.1.
TFEL/Glossary libraryTwo new entries have been added in the glossary:
StrainMeasure: glossary name associated with the strain
measure.DualStress: glossary name associated with the dual
stress of the strain measure.MFrontCast3M 21While the so-called umat interface of this solver is
unchanged, two additional material properties are now required to solve
mechanical problem where thermal exansion are taken into account:
TREF: the reference temperature for the computation of
the thermal expansion.TALP: the reference temperature for the thermal
expansion coefficient.Those material properties are automatically added by the
castem21 interface in the list of the material properties
required by the behaviour.
The castem interface, and its alias called
umat for historical reasons, are left unchanged and shall
be used for versions prior to Version 21.
amitex
interfaceThe amitex interface is mostly an alias for the
castem interface, i.e. the interface for the
Cast3M interface prior to Version 21 and also
generates an input file template which is meant to be copy-pasted into
the material.xml file of the user.
Here is an example of such a template:
<!--
Simple template for use in AMITEX_FFTP.
You may copy-paste those lines in your material.xml file
and adjust:
- the material number I,
- the path to the library (currently UmatBehaviour),
- the coefficients and initial internal variables values
which are currently replaced by three dots.
-->
<Material numM="I" Lib="UmatBehaviour" Law="umatplasticity">
<!-- material property YoungModulus -->
<Coeff Index = "1" Type = "Constant" Value = "..." />
<!-- material property PoissonRatio -->
<Coeff Index = "2" Type = "Constant" Value = "..." />
<!-- material property MassDensity -->
<Coeff Index = "3" Type = "Constant" Value = "..." />
<!-- material property ThermalExpansion -->
<Coeff Index = "4" Type = "Constant" Value = "..." />
<!-- material property H -->
<Coeff Index = "5" Type = "Constant" Value = "..." />
<!-- material property s0 -->
<Coeff Index = "6" Type = "Constant" Value = "..." />
<!-- internal state variable ElasticStrain -->
<IntVar Index = "1" Type = "Constant" Value = "..." />
<IntVar Index = "2" Type = "Constant" Value = "..." />
<IntVar Index = "3" Type = "Constant" Value = "..." />
<IntVar Index = "4" Type = "Constant" Value = "..." />
<IntVar Index = "5" Type = "Constant" Value = "..." />
<IntVar Index = "6" Type = "Constant" Value = "..." />
<!-- internal state variable EquivalentPlasticStrain -->
<IntVar Index = "7" Type = "Constant" Value = "..." />
</Material>The strain measure and the dual stress can now be saved in auxiliary state variables using the following syntax:
@StrainMeasure{
save_strain: true,
save_stress: true
};If requested, the strain measure will be saved in an auxiliary state
variable internally called saved_strain_measure and whose
glossary name is StrainMeasure.
If requested, the dual stress will be saved in an auxiliary state
variable internally called saved_dual_stress and whose
glossary name is DualStress.
Explicit solvers often require the behaviour to compute an upper bound of the speed of sound in the material to compute a critical time step.
The new code @SpeedOfSound to perform this
computation.
Inside this code block, the mass density in the initial configuration
is available in a variable called rho_m0 (one may use the
ρₘ₀ alias if UTF-8 encoding is used).
The code block must set the variable v_sound (one may
use the vₛ alias if UTF-8 encoding is
used)
To avoid any conflict between versions of TFEL and
client projects (mostly the MGIS
project, we have introduce the notion of API
versioning.
By conventions, previous versions are said to use Version 0 of the
API of the
generic interface. This new version thus introduces Version 1 of the API. TheAPIversion is now exported as a new symbol which can be retrieved by client projects. Those projects thus can check at runtime whichAPI`
is used by the behaviours they may use.
In practice, users of the MGIS
project shall upgrade their MGIS’ versions.
GenericBehaviourInterface:
rotateArrayOfTangentOperatorBlocks is not correctly
implementedFor more details, see: https://sourceforge.net/p/tfel/tickets/263/
automakeFor more details, see: https://sourceforge.net/p/tfel/tickets/262/
ndarray.cxx sourceFor more details, see: https://sourceforge.net/p/tfel/tickets/258/
When the thermal expansion is handled by a behaviour, the thermal
expansion coefficients are now automatically exported as material
properties when compiling the behaviour behaviour with the
Cast3M and Cyrano interfaces.
The names of the functions associated with those thermal expansion coefficients can be retrieved by:
getUMATLinearThermalExpansionCoefficientsEntryPoints method
of the ExternalLibraryManager class.linear_thermal_expansion_coefficients_epts data
member of the ExternalBehaviourData class.For more details, see: https://sourceforge.net/p/tfel/tickets/240/
For more details, see: https://sourceforge.net/p/tfel/tickets/236/