Products: ABAQUS/Standard ABAQUS/Explicit
The parametric input capability allows you to create an ABAQUS input file in which:
Any number of input parameters is defined by assigning a value to each one of them.
The parameters defined in the input file are used in place of input quantities.
The parameters are evaluated according to their definition and are substituted for the parametrized input quantities before an analysis is run.
You must define all the parameters you wish to use in an analysis by assigning a value to them. The Python language (Lutz, 1999) is used to perform parameter evaluation and substitution; hence, parameter definitions are required to follow the Python syntax rules discussed later in this section. These parameters can then be used in place of input quantities.
|Input File Usage:||Use the following option to define parameters:|
Use these parameters in place of input quantities by delimiting them with < >.
For example, the following input defines the two parameters width and height, which are then used to define beam section properties:
*PARAMETER width = 2.5 height = width*2 *BEAM SECTION, SECTION=RECT, ELSET=name, MATERIAL=name <width>, <height>
In this simple example models with beams of different cross-sections can be obtained simply by changing the values of the parameters.
Parameters are user-named variables to which you assign values. When a parameter is used instead of a value, the value of that parameter is substituted. There are two basic types of parameters: independent parameters and dependent parameters.
Independent parameters are those that do not depend on any other parameters. The following are examples of independent parameters:
thickness = 10.0 area = 5.0**2 length = 3.0*sin(45*pi/180.0) # convert degrees to radiansPython expressions using numbers and numerical operations (such as addition, multiplication, and exponentiation) can be used to define independent parameters. Arithmetic support in Python is discussed later in this section.
Dependent parameters are those that depend on other parameters (dependent or independent). Dependent parameters can be defined in one of two ways: using a mathematical expression or using a tabular dependence.
Python parametric expressions involving operations between numbers and parameters are used to define expressionally dependent parameters. In the following example area and mom_inertia are dependent parameters:
width = 2.0 height = 5.0 area = width*height mom_inertia = area*height**2/12.0
Tabular dependence between parameters is defined by specifying the dependent and independent parameters as well as a dependence table. The table that defines the dependence between the parameters must have as many values per line as the number of dependent parameters plus the number of independent parameters for which it is going to be used. The table must contain only real values; dependent parameter values are given first, followed by independent parameter values. Parameter names and character strings cannot be used in a table.
The evaluation of tabularly dependent parameters by interpolation between values in a table will result in these parameters being assigned real values. If it is necessary that the tabularly dependent parameters be integer numbers, the real numbers must be converted to integer numbers as described later in the Python language section.
When the tabularly dependent parameters are functions of only one independent parameter, the tabular data must be given in order of increasing values of the independent parameter. ABAQUS then interpolates linearly for values between those given. The dependent parameters are assumed to be constant outside the range of the independent parameters used in a table. When the tabularly dependent parameters depend on several independent parameters, the variation of the dependent parameters with respect to the first independent parameter must be given at fixed values of the other independent parameters, in ascending values of the second independent parameter, then of the third independent parameter, and so on. The table lines must always be ordered so that the independent parameters are given increasing values. This process ensures that the value of each dependent parameter is completely and uniquely defined for all values of the independent parameters.
The fact that the definition of the dependence table is separate from the assignment of the dependence to particular parameters means that the same table can be used for multiple sets of dependent/independent parameters. This is useful when there are different instances of the same kind of input data; for example, multiple material definitions that use the same dependence but different sets of parameters.
Because the evaluation of parameters is procedural (see “Parameter evaluation” below), a parameter dependence table must always be defined before it is used to specify tabular parameter dependencies.
Independent parameters in tabular dependence definitions are treated as independent for the purpose of defining this dependency; however, these “independent” parameters can be defined to depend on other parameters in a preceding parameter definition.
|Input File Usage:||Use the following option to define a parameter dependence table:|
*PARAMETER DEPENDENCE, TABLE=name, NUMBER VALUES=n table with n values per line
Use the following option to define the dependent and independent parameters that are used in the dependence table:
*PARAMETER, TABLE=name, DEPENDENT=(parList), INDEPENDENT=(parList)
Some general rules apply to all parameters used in ABAQUS input files. These rules are described in the following subsections.
Parameters are evaluated by ordered execution of the parameter definitions as they appear in the input file. For example, the input
*PARAMETER x = 2 y = x + 3 x = 4gives x=4 and y=5, not x=4 and y=7. The input
*PARAMETER y = x + 3 x = 4is flagged as an error because y cannot be evaluated by ordered execution of the input. In other words, there is no deferred execution of the parameter definitions.
It is possible to define parameters anywhere in the input file, even after parameters have been used in place of input quantities, since the parameter definitions are always processed before any other input options are processed.
Parameters can also be defined and used in place of input quantities in an input file used for a restart analysis. However, parameters defined in the input file for the original analysis (from which the restart run is continued) are not available in the restart analysis.
When the parameterized data are processed, ABAQUS assigns the parameter values as determined at the end of parameter evaluation. An error is reported if a parameter used in place of input quantities has not been assigned a value. Later, the analysis input file processor performs its usual checks on the validity of the parameter values with respect to the options in which they are being used.
Data given to define a parameter, a parameter dependence table, or a parameter shape variation cannot be parameterized. For example, the input
The data type of a parameter is deduced from its definition. An integer parameter results from assigning an integer literal value to the parameter. Similarly, a real parameter arises from assigning a real literal value to the parameter. Integers are promoted to reals if they are used in operations containing reals. A character string parameter results from assigning a character string literal value to the parameter.
The input option context in which the parameter is used dictates the data type that the parameter must have. Parameters of real data type should be used in place of real ABAQUS input quantities. Parameters of integer (or character string) type should be used in place of integer (or character string) type input quantities, respectively. In some instances, mismatches between the input context and the type of the substituted parameter will cause the analysis input file processor to flag these instances as input errors. For example, the input
*PARAMETER int_pts = 5.0 *SHELL SECTION 10.0, <int_pts>will cause the analysis input file processor to report an error because the number of integration points specified for a shell section must be an integer. However, the input
*PARAMETER thick = 5/4 *SHELL SECTION <thick>,will be accepted by the analysis input file processor without a warning being flagged; as a result of doing integer division, this input gives a shell thickness of 1 (not 1.25). In conclusion, you can rely on the analysis input file processor to catch only some data type errors.
From the point of view of design activities (sensitivity analysis, parametric studies, etc.) parameters can be continuous valued or discrete valued. A continuous-valued parameter is differentiable and can, thus, be used for design sensitivity analysis purposes. A discrete-valued parameter is not differentiable and can, thus, not be used for design sensitivity analysis purposes; however, it can be used for parametric studies. Examples of continuous-valued parameters may be a shell thickness or a material property. Examples of discrete-valued parameters may be the number of integration points through the thickness of a shell, or an element type. Continuous-valued parameters generally coincide with physical (design) input quantities, while discrete-valued parameters generally coincide with finite element (numerical approximation) input quantities.
ABAQUS treats parametrization of “size” and “shape” quantities somewhat differently. Parametrization of shape input quantities is discussed in a separate section (see Parametric shape variation, Section 2.1.2).
Size input quantities are understood to include all ABAQUS input quantities except those that relate to shape. Size input quantities include section properties, material properties, orientation properties, prescribed conditions, interaction definitions and properties, and analysis procedure data.
The following example shows the parametrization of shell section input using three independent parameters of differing data types:
*ELSET, ELSET=<shell_set>, GEN 1, 111, 10 *PARAMETER shell_set = 'lining' shell_thick = 1.E2 num_int_pts = 5 *SHELL SECTION, ELSET=<shell_set>, MATERIAL=name <shell_thick>, <num_int_pts>
The following example shows the parametrization of a three-layer composite shell section using expressional-dependent parameters. In this example the thickness parameter can be used to change the thickness of the layers of the composite section uniformly.
*PARAMETER thickness = 10. layer1_thick = 0.15*thickness layer2_thick = 0.6*thickness layer3_thick = 0.25*thickness *SHELL SECTION, ELSET=, COMPOSITE <layer1_thick>,num int pts, material name, orientation <layer2_thick>,num int pts, material name, orientation <layer3_thick>,num int pts, material name, orientationThis parametrization requires that dependent parameters be created for the three input quantities (layer1_thick, layer2_thick, layer3_thick) that each depend on the independent parameter (thickness).
The following example shows the parametrization of the section properties of a box beam. The height and wall thicknesses of the beam section are parameters that depend tabularly on the section width.
*PARAMETER a = 60. *PARAMETER DEPENDENCE, TABLE=sectprop, NUMBER VALUES=6 25.0, 1.04, 1.04, 1.04, 1.04, 50.0 50.0, 4.17, 3.13, 2.08, 2.50, 100.0 75.0, 9.38, 6.24, 3.13, 4.90, 150.0 *PARAMETER, TABLE=sectprop, DEPENDENT=(b, t1, t2, t3, t4), INDEPENDENT=(a) *BEAM SECTION, SECTION=BOX, ELSET=beams, MATERIAL=steel <a>, <b>, <t1>, <t2>, <t3>, <t4>The above parametrization creates dependent parameters (b, t1, t2, t3, t4) that each depend on the independent parameter (a). Usage of tabular dependence allows the definition of the dependencies of input quantities on parameters to be confined to the parameter definitions; i.e., separate from the options where parametrization of input quantities is done. An advantage of this method of parametrization is that the same parameter dependence table can be used for different parameters in different input options. For example, you may wish to use beams of different cross-section dimensions in different parts of the structure being modeled. The parameter dependence table can be reused with new dependent (bb, tt1, tt2, tt3, tt4) and independent (aa) parameters.
*PARAMETER aa = 65. *PARAMETER, TABLE=sectprop, DEPENDENT=(bb, tt1, tt2, tt3, tt4), INDEPENDENT=(aa) *BEAM SECTION, SECTION=BOX, ELSET=columns, MATERIAL=steel <aa>, <bb>, <tt1>, <tt2>, <tt3>, <tt4>
In options where predefined field variable dependence is supported, this method of parametrization provides a clear separation between predefined field variable dependence and parameter dependence; therefore, field variable and parameter dependence can never be confused. Consider, for example, the case of perfect plasticity properties for a metal where the yield stress depends on a field variable and is also parametrized to depend tabularly on the carbon content of the metal alloy.
*PARAMETER carbon = 0.01 *PARAMETER DEPENDENCE, TABLE=yield_data, NUMBER=4 ys_fv1 val 1, ys_fv2 val 1, ys_fv3 val 1, carbon val 1 ys_fv1 val 2, ys_fv2 val 2, ys_fv3 val 2, carbon val 2 ys_fv1 val 3, ys_fv2 val 3, ys_fv3 val 3, carbon val 3 ys_fv1 val 4, ys_fv2 val 4, ys_fv3 val 4, carbon val 4 *PARAMETER, TABLE=yield_data, DEPENDENT=(ys_fv1, ys_fv2, ys_fv3), INDEPENDENT=(carbon) *MATERIAL, NAME=alloy *PLASTIC, DEPENDENCIES=1 <ys_fv1>, , , fv val 1 <ys_fv2>, , , fv val 2 <ys_fv3>, , , fv val 3Consider, for example, the case of metal creep properties where the creep material data are parameters that depend tabularly on the carbon content of the metal alloy. In addition, one of the creep parameters, A, also depends on a predefined field variable.
*PARAMETER carbon = 0.01 *PARAMETER DEPENDENCE, TABLE=creepdata, NUMBER=6 A_fv1 val 1, A_fv2 val 1, A_fv3 val 1, n val 1, m val 1, carbon val 1 A_fv1 val 2, A_fv2 val 2, A_fv3 val 2, n val 2, m val 2, carbon val 2 A_fv1 val 3, A_fv2 val 3, A_fv3 val 3, n val 3, m val 3, carbon val 3 A_fv1 val 4, A_fv2 val 4, A_fv3 val 4, n val 4, m val 4, carbon val 4 *PARAMETER, TABLE=creepdata, DEPENDENT=(A_fv1, A_fv2, A_fv3, n, m), INDEPENDENT=(carbon) *MATERIAL, NAME=alloy *CREEP, DEPENDENCIES=1 <A_fv1>, <n>, <m>, , fv val 1 <A_fv2>, <n>, <m>, , fv val 2 <A_fv3>, <n>, <m>, , fv val 3This example shows that any combination of dependencies on predefined field variables and/or dependent parameters can be defined.
Parameter statements in parameter definitions are required to follow the syntax and semantics of the Python language (note that the parameter dependence table and parameter shape variation definitions follow the usual ABAQUS input syntax rules). The subset of the Python language that is endorsed is documented here.
Python statements in parameter definitions can be continued over multiple lines by terminating each line with a backslash character (\). The *PARAMETER keyword lines can be continued onto the following line using a trailing comma since they are treated like other ABAQUS keyword lines.
Comments in a parameter definition start with the number character (#) and continue to the end of the line. However, comments in a parameter dependence table or parameter shape variation definition are indicated by the usual ABAQUS input syntax convention (**).
Parameter names must begin with a letter and can contain the underscore character (_) and numbers. Parameter names are case sensitive.
Data types are limited to character strings, integers, and reals.
Strings are delimited with single or double quotation marks (' ' or ” ”). Backward single quotation marks (` `) are not permitted. Character strings should not contain the backslash character (\).
Integers are created by assignment to integer literals (for example, aInt = 2).
Reals are created by assignment to real literals (for example, aReal = 1.0). Real numbers can be given with or without an exponent. Any exponent must be preceded by E or e. The following line shows five acceptable ways of entering the same real number:
-12.345, -1234.5E-2, -0.12345E+2, -0.12345E2, -0.12345e2The syntax
-0.12345D+2(allowed elsewhere in the ABAQUS input file) is not valid in Python.
If integers and reals are mixed in expressions, integers are promoted automatically to reals. Explicit type conversion can be obtained using:
int(aReal) aReal converted to integer type
float(anInt) anInt converted to real type (float is the same as real)
str(anIntOrReal) anIntOrReal converted to character string type
'anIntOrReal' anIntOrReal converted to character string type
Standard support for operators is provided:
x x negated
+ x x unchanged
x + y sum of x and y
x y difference of x and y
x * y product of x and y
x / y quotient of x and y
x**y x to the power y
The following utility functions are supported:
abs(x) absolute value of x
acos(x) arc cosine of x (result is in radians)
asin(x) arc sine of x (result is in radians)
atan(x) arc tangent of x (result is in radians)
cos(x) cosine of x (x is in radians)
log(x) natural logarithm of x
log10(x) base 10 logarithm of x
pow(x,y) x to the power y (equivalent to x**y)
sin(x) sine of x (x is in radians)
sqrt(x) square root of x
tan(x) tangent of x (x is in radians)
Jobs with parametrized input files are submitted to ABAQUS in the usual way; for example,
abaqus job=job-name input=input-filewhere it is assumed that an input file named input-file.inp exists.
ABAQUS searches input-file.inp and any *INCLUDE input files for parameter, parameter dependence table, and parameter shape variation (Parametric shape variation, Section 2.1.2) definitions, as well as parameter names inside < > that may have been used in place of input quantities. If any of the above are found, ABAQUS will interpret the parametrized input file and perform the tasks of parameter evaluation and substitution.
As a result, a modified input file that is free of parameter and parameter dependence table definitions and <parameter> instances is produced. This file is named job-name.pes and is subsequently submitted for execution of an analysis. The execution procedure of a parametrized input file, except for the additional processing of parameter shape variation definitions in the analysis input file processor, does not differ from that of a non-parametrized input file. All the files generated by the parametrized input job will be named job-name with the appropriate extension appended to it.
You can specify an execution mode in which only parameter processing (evaluation and substitution) is carried out. The parameter check execution mode is mutually exclusive of other execution modes, such as complete analysis, data check, continuation of a data check, conversion of results, or recovery (see Execution procedure for ABAQUS/Standard and ABAQUS/Explicit, Section 3.2.2).
A parameter check run is useful in situations where you have defined complex parametrization in the input. In these cases you may want to study the results of parameter evaluation and substitution before proceeding further.
A parameter check run does not permit continuation of the execution in a subsequent run; the job must be rerun from the beginning.
|Input File Usage:||Enter the following input on the command line:|
abaqus job=job-name input=input-file parametercheck
Display of the results of parameter evaluation and substitution in the data file is described in this section. Visualization of parameter shape variations is described in Parametric shape variation, Section 2.1.2.
The data (.dat) file contains information about the model definition generated by the analysis input file processor. You can control the amount of output generated by the analysis input file processor; see Controlling the amount of analysis input file processor information written to the data file” in “Output, Section 4.1.1, for details. In particular, you can specify whether or not the original input (.inp) file is echoed to the data file (by default, it is not).
In the case of parametric input this file will generally contain a number of parameter, parameter dependence table, and parameter shape variation definitions, as well as a number of <parameter> instances. To verify the definition of parametric input, you can create a modified version of the original input file showing the parameters and their values (this file is named job-name.par). You can also create the job-name.pes file, which is the modified version of the original input file that is free of parameter and parameter dependence table definitions, as well as <parameter> instances.