Multiple Nonlinear Load Case Analysis

A nonlinear load case refers to a set of steps comprising a particular load history. For example, the operational environment of an airplane might be broken into three nonlinear load cases: (1) slow ascent and then bank left, (2) rapid ascent and then bank right, and (3) descent, where load cases (1) and (2) each consist of two steps and load case (3) consists of a single step.

A multiple nonlinear load case analysis is conceptually equivalent to executing each nonlinear load case as a stand-alone analysis, with any steps comprising the common base state repeated in each stand-alone analysis. A multiple nonlinear load case analysis can be more efficient than the equivalent stand-alone analyses when the execution costs of the analysis preprocessor and the solution of the base state are significant relative to the cost of the nonlinear load cases.

If only the linear response of the structure is required for each load case, a linear multiple load case analysis may be more efficient than a nonlinear load case analysis. For more information, see Multiple Load Case Analysis.

The steps comprising a nonlinear load case are defined within an input file specific to that load case. A set of nonlinear load case input files is then referenced, along with the input file defining the model, in a manifest file. The input file defining the model must be the first input file given in the manifest file. The manifest file is submitted for execution.

The input file that defines the model can also include the steps that define the first nonlinear load case or the shared base state for all nonlinear load cases. Each additional input file given in the manifest file defines a new nonlinear load case. You can define one and only one load case within each input file.

You run a multiple load case analysis by submitting the manifest file on the command line during the abaqus execution procedure.

Nonlinear load cases are executed in a sequential fashion in the order they are defined in the manifest file. The input file defining a given nonlinear load case is processed by the analysis input file processor before execution of the nonlinear load case. If errors are encountered during either the input file processing or during the execution of a nonlinear load case, the analysis attempts to proceed to the next nonlinear load case.

The base state and all nonlinear loads cases share the printed output (.dat) file, message (.msg) file, and status (.sta) file for the job. The base state and all nonlinear load cases can either share the same output database or create separate output databases (see Results Output Format). If each nonlinear load case creates its own output database, the base state results are included in the output database for each nonlinear load case.

Each nonlinear load case can consist of any number of general and perturbation procedures. Rules for propagation of step attributes (such as loads, boundary conditions, and output requests) follow the same conventions as those for stand-alone analyses. For more information, see Multiple Steps.

By default, the base state for all nonlinear load cases is the initial state of the model (the model plus any initial conditions). Any steps that you define along with the model in the first input file given in the manifest file form the first nonlinear load case. This is shown schematically for a sample set of input files in Figure 1.

Impact of BASE STATE=NO on the selection of the base state for a sample multiple nonlinear load case analysis.

You can change the default behavior so that the steps that you define in the first input file given in the manifest file form the base state for all nonlinear load cases. This is shown schematically for a sample set of input files in Figure 2.

Impact of BASE STATE=YES on the selection of the base state for a sample multiple nonlinear load case analysis.

For example, consider the analysis of an airplane subject to three nonlinear load cases: (1) slow ascent and then bank left, (2) rapid ascent and then bank right, and (3) descent. In this example load cases (1) and (2) each consist of two steps and load case (3) consists of a single step. Initial velocities are applied to the airplane and serve as the base state for all three load cases. Figure 3 and Figure 4 show two possible configurations for the input files in this example.

First example configuration.

Second example configuration.

You can write results for the base state and all nonlinear load cases to the same output database. To do so, the step name must be unique for all steps in the base state and in all load cases. The output database files are named according to the analysis job name.

Alternatively, you can write results to separate output databases for each load case. In this case the base state results are duplicated in each output database. The step name must be unique for all steps across the base state and any individual load case. The first set of output database files are named according to the analysis job name. Each subsequent set of output database files is named according to the input file name for the nonlinear load case.

If element or contact pair removal (Element and Contact Pair Removal and Reactivation) can be used during some nonlinear load cases and you cannot activate the capability in the first input file of the manifest file, you must activate the capability in the manifest file.

By default, results are written to the output databases at the start of the first step of each nonlinear load case. This can result in the duplication of a significant amount of data if the number of nonlinear load cases is large or the results requested for each nonlinear load case are identical. The size of the output databases can be reduced by skipping output at the start of each nonlinear load case.