TFEL
, MFront
and MTest
TFEL/Glossary
libraryMFront
GenericBehaviourInterface
: rotateArrayOfTangentOperatorBlocks
is not correctly implementedautomake
ndarray.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.MFront
Cast3M 21
While 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{
true,
save_strain: true
save_stress: };
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. The
APIversion is now exported as a new symbol which can be retrieved by client projects. Those projects thus can check at runtime which
API` 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/
automake
For 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/