`@Class`#

Description#

User behavior models are declared in a class definition which resembles a C++ class, including special pre-processor directives. These directives always begin with a @ sign. It is always possible to include C++ language code in the class definition, including variable and method declarations.

The class creator is generated by the pre-processor, so that method is not allowed in the class declaration. Manipulations are possible in the creator however by using the @SetUp or @UserRead commands.

Syntax#

The basic form of a ZebFront class declaration is summarized below:

@Class NAME_OF_CLASS : PROCESSOR_TYPE { $~\,~\,$ @Name class_name; $~\,~\,$ @SubClass type obj_name; $~\,~\,$ @SubClass type obj_name @Params param_list; $~\,~\,$ @Coeff coeff, …, coeffN; $~\,~\,$ @Coeff coeff size, ... ; $~\,~\,$ @Coeff list @Factor fact; $~\,~\,$ @Grad var_size declaration; $~\,~\,$ @Flux var_size declaration; $~\,~\,$ @sVarInt list; $~\,~\,$ @sVarAux list; $~\,~\,$ @sVarUtil list; $~\,~\,$ @Tags tag declarations $~\,~\,$ @Integrate $~\,~\,$ @Implicit $~\,~\,$ additional C++ code };

The processor type defines the type of model which will be created, and therefore the allowable syntax and the base class from which it is derived (as shown on page ).

The parameters in the above syntax have the following meanings:

class_name: the name to be used in an input file to identify an object of this type. For behaviors, this corresponds to the command ***behavior. The default name is the class name in all lower case.
type: a valid sub-class type. Sub-classes may in essence be any class which satisfies a certain set of requirements ¹ ¹As these requirements will soon change, no more description will be given… e-mail foerch@nwnumerics.com if you have questions. Sub classes may not yet have integrated or auxiliary variables; these classes are just used as utility equations with coefficients.
obj_name: the name to be used for the object instance. This name will result in an input command with the same name.
param_list: The parameters to be sent to a sub-class read method. The default list is the file, problem (tensor) size, and behavior. The default would be input as: | SubClass X x @Params file,psz,this;
coeff: a character name for a coefficient. Names must not be duplicated with other variable names.
size: a size specifier. Coefficients may be loaded as single values (no size), as fixed dimension arrays using the syntax [x] where x is the desired size, as variable diemsnioned entities using [0-N] for the size, or in terms of another object using [!X] with X being another object. Constant or other function values are also allowed, permitting the following two cases: @sVarInt gamma [12]; @sVarInt gamma1 [get_gamma_size(1)]; where the method get_gamma_size is defined in standard C++ within the class.
factor: a factor to calculate which will be multiplied to the coefficient. This may be any expression calculatable after the coefficients are loaded, such as: @Coeff C @Factor 2./D; with D being another coefficient. The factor only applies the initial value of D however, and thus cannot be used for variable coefficient interrelations.
s: a size specifier. Sizes may be s for scalar variables, t for symmetric tensors, u for unsymmetric tensors, or v for vectors ² ²vectors are not yet implemented.
num: is an optional size declaration. This size is the number of repeated instances of the variable to be stored as an array. The size may either be an explicit number or use an indicator based on the number of a specific coefficient entered. For example, if a coefficient C was given an internal variable associated to it may be declared: @tVarInt alpha [!C]; from which variable are accessed as alpha[1], to alpha[!C-1] or equally alpha[!alpha-1] (note that indexes start at $0$.
list: a comma separated list of object names. The syntax is the same as standard C++ variable list. See the end of this page for various examples. Each variable may be given an optional size specification for variables to be stored in list format.

Example#

The examples here attempt to demonstrate some more complex combinations of the class declaration. First is a FEM behavior for finite deformation. The gradient variable is the deformation gradient $\bf F$ while the flux variable is the Cauchy stress $\ten \sigma$. The porgram can use the default flux name of sig while it defines a non-symmetric tensor named F for $\ten F$.

@Class BATHE_ROT : BASIC_NL_BEHAVIOR {
   @SubClass ELASTICITY elasticity;
   @Coefs    K, n, R0, Q, b, C1, D1, C2, D2;
   @Grad     usz F;
   @uVarInt  Fp;
   @sVarInt  evcum;
   @tVarInt  alpha1,alpha2;
};

The following example class definition is more modular in nature. ³ ³$Z7PATH/calcul/zZfrontBehavior/ModularPlastic.z This class uses several of the behavior “bricks” which are standard in the Z7 behavior library. Also, the coeffcient C is variable in number, while the coefficient D and variables X and alpha are sized to match C. This allows the user to enter as many C terms as desired.

@Class MODULAR_PLASTIC_BEHAVIOR : BASIC_NL_BEHAVIOR {
   @Name     modular_plastic;
   @SubClass ELASTICITY elasticity;
   @SubClass CRITERION  criterion;
   @SubClass FLOW       flow;
   @SubClass ISOTROPIC_HARDENING  isotropic;

   @Coefs    C [0-N] @Factor 1./1.5;
   @Coefs    D [!C];
   @tVarInt  eel, alpha [!C];
   @sVarInt  evcum;
   @tVarAux  X [!C], evi;
   @tVarAux  Xtot;
   @tVarUtil m [!C];
   @tVarUtil Xdot;
};

In one final example, a case of multiple gradiant flux variables is given. Here we have a behavior designed to be compatible with a small deformation, icompressible element.

@Class ADIABATIC_INCOMP_PLASTICITY : BASIC_NL_BEHAVIOR {
   @Name     adiabatic_incompressible;
   @SubClass ELASTICITY elasticity;
   @SubClass ISOTROPIC_HARDENING  isotropic;

   @Grad     tsz eto;
   @Grad     1 press;
   @Flux     tsz sig;
   @Flux     1 dvolu;

   @Coefs    pCp, chi, alpha_t;
   @tVarInt  eel;
   @sVarInt  epcum, T;
   @tVarAux  epi;
   @Implicit
};

@Class

On this page

@Class#

Description#

Syntax#

Example#

`@Class`#