Introduction to Behaviors

Material behaviors in Z-mat use by far the most dynamic and object oriented input of all the Z-set modules. This is because behaviors are a set of constitutive equations which get built from fundamental “building bricks” of sub-models. There is widespread re-use of all these “bricks” between different behavior models. It is therefore necessary to adjust our input syntax (or at least documentation of it) to allow for more flexibility.

Classes

The most important concept for this chapter is the notion of a class of permissible options, of which the user will choose one or more objects from that class in the material definition. A class is an abstract notion of basic functionality, and will henceforth be denoted by the following convention: EXAMPLE_CLASS indicating that an object of type EXAMPLE_CLASS is permitted. In the handbook, one will find another section with heading EXAMPLE_CLASS which describes the different types allowable for the class.

An example is an ELASTICITY class which handles the calculation of stress from a strain, usually employing a 4th order tensor of various modulus coefficients. Because of this very general function, many behavior models allow for an ELASTICITY instance. In turn, the elasticity class has many possible types which one can select to fill in an elasticity object (isotropic, orthotropic, etc).

**elasticity <ELASTICITY>

The keyword **elasticity used here is in fact specific to the behavior model. While we frequently see the same keyword indicating classes between behaviors, this is not necessarily so. The function of each sub-command will be described in the discussion of the behavior model itself. What defines the syntax which follows this line is the ELASTICITY notation, indicating an elasticity matrix should be input. Again, the use should then go to the ELASTICITY section of the handbook, and investigate the possible models for this option.

Many behavior models also include the possibility of multiple instances of certain keywords. These possibilities will be described in the section of the containing class (behavior is a “material piece” class, but there are many others which can contain sub-pieces themselves). The standard notation for multiple instances of a class is to include three dots following the data entry line:

*kinematic <KINEMATIC>
 ...

This means that the material at this location can take any number of *kinematic entries, in any order, and with no restriction on type.

Example

An example file follows, which is of a simple elasto-viscoplastic model with non-linear isotropic hardening, and two kinematic hardening components. Note that the behavior has taken two objects, an elasticity matrix and a “potential” (dissipation potential with an inelastic deformation associated to it). The material behavior is gen_evp which stands for generalized elasto-viscoplastic (see gen_evp. The potential has in turn taken on a number of sub-objects: criterion, flow, kinematics and an isotropic hardening. This behavior actually allows for more than one **potential instance, so very complex behaviors are possible.

***behavior gen_evp
 **elasticity isotropic
       young 260000.
       poisson 0.3
 **potential associated ev
   *criterion mises
   *flow norton
       n  7.0
       K  400.
   *kinematic linear
       C  15000.0
   *kinematic nonlinear
       C  6000.0
       D  100.0
   *isotropic nonlinear
       R0 130.0
       Q  20.0
       b  500.0
***return

Another important thing to notice here is the coefficient C is entered after each *kinematic entry. These coefficients are distinct in the behavior because they belong strictly to the kinematic objects. This totally illuminates the possible conflicts inherent with hard-coding the model to have for example C1 and C2.

Grad-Flux

The compatibility of material behaviors with the element is determined dynamically based on their gradient (or primal) and flux (dual) variables. These can also be thought of as the material input-output combination. These variables are also observable state variables and observable associated forces. Some of the primal-dual variable combinations in Z-mat are as follows ^{1 1}Z-mat used for other codes such as ABAQUS establish a similar relationship, where the UMAT interface adjusts itself according to the material primal-dual couple:

primal-dual variables	Description
eto - sig	small deformation \(\ten \varepsilon-\ten \sigma\)
F - sig	updated Lagrangian large-strain \(\ten F-\ten \sigma\)
dT - q	thermal analysis
dC - J	diffusion analysis

The process relative to element integration is shown schematically below. Non-linear finite element analysis consists of a loop over all elements in order to fabricate the global DOF residual vector (and possibly fabricate the stiffness if needed). In turn, there is a loop within the element over the integration points in order to numerically integrate the elements volume integrals. At each integration point, the new increment in primal variable is calculated using the increment of degrees of freedom, and their derivatives (this is where grad comes from), and this is passed to the material behavior with the current value of state variables.

Material variables

As introduced in the previous section, material behaviors in Z-mat are dynamically “created” by the user through the assemblage of material sub-objects. The example given of a gen_evp behavior was certainly structured this way. Of interest to the user is what variables are contained in the model, and what is available for output ^{2 2}Because of the dynamic nature of the object construction, it is often difficult to strictly define the names of all the stored variables ahead of time. Users are thus strongly advised to observe the stored variables by using the -v command line switch or **verbose output option..

Principally all material objects (behaviors and their sub-component classes) have the possibility of the following variables:

grad

is the gradient or primal observable input variable.

flux

is the flux or dual output variable. Normally thermodynamically conjugate with the grad.

var-int

integrated state variables. These define the current state of the material, and are the subject of the integration method. Normally the more var-int variables, the higher the cost of local integration.

var-aux

auxiliary variables; normally used for output, or maintaining state information on a total basis (secondary to var-int).

ext-param

External parameters. These are imposed using ***parameter statements in Zebulon, or with field variables in other codes.

coefs

material coefficients. Can depend on any of the above! Note however that the integration method or implementation restrictions can limit such dependence.

Each variable is assigned a name, but unlike other codes where the relationship between model options is hard-coded, the naming scheme is not known a priori. Much of the final naming is up to the user. The example on the next page demonstrates how the names are constructed.

Variable attributes

When asking for specific output of the material variables, some additional attributes are available. These are summarized as follows:

Attributes	Description
scal::fabs	absolute value of scalar
tens::mises	von Mises equivalent of tensor
tens::trace	Trace of tensor
tens::p1	Principal eigen values of tensor; also ::p2 and ::p3
vec::eq	Equivalent of vector

An example of accessing these secondary variables in a Zebulon output statement follows:

***output
 **component sig::mises sig::p1 sig::p2 sig::p3
             sig11 sig22 sig33 sig12
             eto11 eto22 eto33 eto12

Example

Taking the gen_evp material file example given previously (see example), and running it with verbose set (on by default in Z-mat for ABAQUS, or with a -v switch running in Zebulon or Z-sim) gives the following output:

============================================
Flux Name:
  sig11  sig22  sig33  sig12
Grad Name:
  eto11  eto22  eto33  eto12
var_int Name:
  eel11  eel22  eel33  eel12
  evcum
  al111  al122  al133  al112
  al211  al222  al233  al212
var_aux Name:
  evi11  evi22  evi33  evi12
Default Output:
  eto11  eto22  eto33  eto12
  sig11  sig22  sig33  sig12
  evcum
  evi11  evi22  evi33  evi12
============================================

In fact what happens here is the behavior is put together by the different “bricks,” with each brick naming its own variables. Note that the potential line input was **potential associated ev and that the last key ev was used as a pre-fix for that potentials variables. Thus one has evcum for the plasticity (viscoplasticity in this case) multiplier, and evi## as components of the inelastic strain tensor. The variable construction in this model can be represented as shown below:

Naming conventions

The dynamic nature of the material assembly notwithstanding, some conventions are given in the documentation and reflected in the default naming of variables. A small summary table of some common names follows.

Common variables	Description
eto	total strain
ETO	“material strain” for finite strain. This is the integration of the corotational strain measure – not the logarithmic strain, etc.
sig	Cauchy stress
eel	elastic strain
eth	thermal strain
evcum	cumulated, monotonically increasing scalar measure of viscoplastic strain. Actually the integration of the viscoplastic multiplier.
epcum	cumulated plasticity equivalent of evcum. The naming difference is usually only symbolic.
f	porosity for porous materials.

Material file

The material and global-scope coefficients to be used are defined in a separate file henceforth described as the material file. The material file is a standard ASCII text file of form similar to the main input file. Most instances where a material filename needs to be specified allows an optional integer value for the instance of behavior in that file, the default instance being the first. So, when a material file is opened, the program will search for the \(n\)-th occurrence of the keyword ***behavior, skipping all other data contained before. Frequently for example and verification problems, the material file is given in the same physical file as the referring input file for compactness and file management purposes ^{3 3}Note that we frequently find this the advisable approach for production runs as well, as it avoids confusion or possible version conflicts when numerous runs are to be made..

Regardless of how or where the material file is located, the material file is a separate entity from the other input commands, with an independent command hierarchy starting at the ***-level. The general structure of this file is the following:

***behavior BEHAVIOR [ modifiers ] \(~\,\) **functions list of function declarations \(~\,~\,\) ... \(~\,\) **behavior sub-procedures ... \(~\,\) **coefficient coefficient_name COEFFICIENT \(~\,~\,\) … \(~\,\) **save_coefficients \(~\,~\,\) coef-names \(~\,\) **plane_stress ***return

***behavior

begins the definition of a material law. The options which follow are of course specific to each material model.

**coefficient

⁴Older definitions with the ***coefficient command outside the ***behavior and ***return commands are no longer allowed.

indicates the definition of intrinsic coefficients which are not specific to material laws ^{4 4}Older definitions with the ***coefficient command outside the ***behavior and ***return commands are no longer allowed.. These coefficients are applicable to all the material models. The allowable global coefficients are summarized below:

Coefs	Description
masvol	volumetric mass of the material
capacity	volumetric heat capacity(\(\rho C_p\))

Units should be coherent within the problem definition. For example, if using SI system, masvol is in \(kg \cdot m^{-3}\) and capacity in \(J \cdot m^{-3} \cdot K^{-1}\), but if using the (\(mm\),\(M\!Pa\),\(s\)) unit system, masvol is in \(ton \cdot mm^{-3}\) and capacity in \(J \cdot mm^{-3} \cdot K^{-1}\).

**plane_stress

indicates that a plane stress behavior is to be used (\(\sigma_{33}=0\)). This is not available with all material behaviors. Zébulon plane stress must not use this option.

**save_coefficients

list coefficient names which are to be saved as output variables. New var-aux variables are created, and therefore increase the total storage for each material integration point. This option is extremely useful when the variation of coefficients is important, such as in coupled problems.

Example

Another example of material file input follows, showing some tabular coefficient input:

***behavior linear_elastic
  **elasticity isotropic
    young temperature humidity
        200000.e0  100.   0.
        100000.0   "      1.
        100000.0   200.   0.
         50000.0   "      1.
    poisson 0.3
  **thermal_strain
    alpha temperature
        1.e-6  0.
        1.e-6  1000.
    ref_temperature 0.0
 **coefficient
    masvol 7.e-9
***return