<!-- source-page: 371 -->

cannot use this feature to append results file output to an old results file; the abaqus append execution procedure must be used for this purpose. Setting fil=new is not allowed for Abaqus/Explicit runs. This option is not applicable for Abaqus/CFD.

# globalmodel

This option specifies the name of the global model’s results file, ODB output database file, or SIM database file from which the results are to be interpolated to drive a submodel analysis. This option is required whenever a submodel analysis or submodel boundary condition reads data from the global model’s results.

The file extension is optional. If you omit the file extension, Abaqus uses the results file. If the results file does not exist, Abaqus uses the ODB output database file. If both the results file and the ODB output database file do not exist, Abaqus uses the SIM database file.

This option is not applicable for Abaqus/CFD.

# cpus

This option specifies the number of processors to use during an analysis run if parallel processing is available. The default value for this parameter is 1 and can be changed in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# parallel

This option specifies the method to use for thread-based parallel processing in Abaqus/Explicit. The possible values are domain and loop. If parallel=domain, the domain-level method is used to break the model into geometric domains. If parallel=loop, the loop-level method is used to parallelize lowlevel loops. See “Parallel execution in Abaqus/Explicit,” Section 3.5.3, for more information on these methods. The default value is domain, which can be changed in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# domains

This option specifies the number of parallel domains in Abaqus/Explicit. If the value is greater than 1, the domain decomposition will be performed regardless of the values of the parallel and cpus options. However, if parallel=domain, the value of cpus must be evenly divisible into the value of domains. The default value is set equal to the number of processors used during the analysis run if parallel=domain and 1 if parallel=loop. The default value can be changed in the environment file (see“Using the Abaqus environment settings,” Section 3.3.1). A restart analysis uses the same number of parallel domains as the original analysis, and the value specified with this option will be ignored.

# dynamic\_load\_balancing

For domain-parallel execution in Abaqus/Explicit (parallel=domain) where the number of domains is larger than the number of cpus, this option activates the dynamic load balancing scheme. Abaqus/Explicit will attempt to improve computational efficiency by periodically reassigning domains to processors in a way that minimizes load imbalance (see “Parallel execution in Abaqus/Explicit,” Section 3.5.3).

<!-- source-page: 372 -->

# mp\_mode

If this option is set equal to mpi, the MPI-based parallelization method will be used when applicable. Set mp\_mode=threads to use the thread-based parallelization method. The default value is mpi on Windows platforms if MPI components are installed; otherwise, thread-based parallel execution is the default behavior. On all other platforms, the default value is mpi. The default setting can be changed in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1). For Abaqus/CFD only mp\_mode=mpi can be used.

# standard\_parallel

This option specifies the parallel execution mode in Abaqus/Standard. The possible values are all and solver. If standard\_parallel=all, both the element operations and the solver will run in parallel. If standard\_parallel=solver, only the solver will run in parallel. The default value is standard\_parallel=all on platforms where MPI-based parallelization is supported.

The parallel execution mode can also be set in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# gpus

This option specifies acceleration of the Abaqus/Standard direct solver. This option is meaningful only on computers equipped with appropriate GPGPU hardware. By default, GPGPU solver acceleration is not activated. The value of this parameter is the number of GPGPUs to be used in an Abaqus/Standard analysis. In an MPI-based analysis, this is the number of GPGPUs to be used on each host.

GPGPU-based solver acceleration can also be set in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# memory

Maximum amount of memory or maximum percentage of the physical memory that can be allocated during the input file preprocessing and during the Abaqus/Standard analysis phase (see “Managing memory and disk use in Abaqus,” Section 3.4.1). The default values can be changed in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1). This option is not applicable for Abaqus/CFD.

# interactive

This option will cause the job to run interactively. For Abaqus/Standard and Abaqus/CFD the log file will be output to the screen; for Abaqus/Explicit the status file and the log file will be output to the screen. The default run\_mode can be set in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# background

This option will submit the job to run in the background, which is the default. Log file output will be saved in the file job-name.log in the current directory. The default method for submitting the job can be set in the environment file by using the run\_mode parameter (see “Using the Abaqus environment settings,” Section 3.3.1).

<!-- source-page: 373 -->

# queue

This option will submit the job to a batch queue. If the option appears with no value, the job will be submitted to the system default queue. Quoted strings are allowed. The available queues are site specific. Contact your site administrator to find out more about local queuing capabilities. Use information=local to see what local queuing capabilities have been installed. The default method for submitting the job can be set in the environment file by using the run\_mode parameter (see “Using the Abaqus environment settings,” Section 3.3.1).

# after

This option is used in conjunction with the queue option to specify the time at which the job will start in the selected batch queue. This capability is supported for each individual site through the Abaqus environment file. (See the Abaqus Installation and Licensing Guide for details.)

# double

This option is used to specify that the double precision executable is to be used for Abaqus/Explicit. The possible values are both, constraint, explicit, and off. This capability is also supported through the Abaqus environment file with the environment variable double\_precision (see “Using the Abaqus environment settings,” Section 3.3.1).

If double=both, both the Abaqus/Explicit packager and analysis will run in double precision.

If double=constraint, the constraint packaging and constraint solver in Abaqus/Explicit will run in double precision, while the Abaqus/Explicit packager and Abaqus/Explicit analysis continue to run in single precision.

If double=explicit, the Abaqus/Explicit analysis will run in double precision, while the packager will still run in single precision. The default value is explicit.

If double=off, the environment file setting is overridden if necessary to invoke both the Abaqus/Explicit packager and Abaqus/Explicit analysis in single precision. For a discussion of when to use the double precision executable, see “Defining an analysis,” Section 6.1.2.

# scratch

This option is used to specify the name of the directory used for scratch files. On Linux platforms the default value is the value of the \$TMPDIR environment variable or /tmp if \$TMPDIR is not defined. On Windows platforms the default value is the value of the %TEMP% environment variable or \TEMP if this variable is not defined. During the analysis a subdirectory will be created under this directory to hold the analysis scratch files. The default value for this parameter can be set in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1).

# output\_precision

This option specifies the precision of the nodal field output written to the output database file (job-name.odb). Using output\_precision=full results in double precision field output for Abaqus/Standard analyses. To obtain double precision field output for Abaqus/Explicit analyses, use the double option in addition to using output\_precision=full. Nodal history output is available only in single precision. This option cannot be used with the recover option.

<!-- source-page: 374 -->

# resultsformat

This option specifies the output format of the results. If resultsformat=odb, the output is written in ODB format only. If resultsformat=sim, the output is written in SIM format only. If resultsformat=both, the output is written in both ODB and SIM formats. The default value is odb. For more information, see “The output database” in “Output,” Section 4.1.1. This option is not applicable for Abaqus/CFD.

# field

This option specifies the format of field output for Abaqus/CFD. If field=odb, field output is written in ODB format. If field=sim, field output is written in SIM format. The default value is odb. For more information, see “Alternate output formats in Abaqus/CFD” in “Output,” Section 4.1.1.

# history

This option specifies the format of history output for Abaqus/CFD. If history=odb, history output is written in ODB format. If history=sim, history output is written in SIM format. If history=csv, history output is written to a file in comma-separated values format.

The default value depends on the setting for the field option. When field=odb, the default is history=odb. When field=sim, the default is history=sim. For more information, see “Alternate output formats in Abaqus/CFD” in “Output,” Section 4.1.1.

# port

This option is used to specify the TCP/UDP port number for co-simulation between solvers using the direct coupling interface, which includes co-simulation between Abaqus and certain third-party analysis programs. Set port equal to the port number used for the connection. The default value is 48000. The default port number that Abaqus uses to initiate communication can be set with the cosimulation\_port parameter in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1). This option is used in conjunction with the host option. For more information, see “Selecting TCP/UDP port numbers” in “Execution procedure for Abaqus: overview,” Section 3.1.1.

# host

This option is used to specify the host name for co-simulation between solvers using the direct coupling interface, which includes co-simulation between Abaqus and certain third-party analysis programs. This option specifies the name of the machine that is hosting the connection. Refer to the third-party program documentation to determine if the host option is required. This option is used in conjunction with the port option.

# csedirector

This option is used to specify the connection (e.g., host:port) for the SIMULIA Co-Simulation Engine director process when performing a co-simulation using the SIMULIA Co-Simulation Engine. The csedirector entry identifies the host name and the TCP/UDP port number for the listening port of the SIMULIA Co-Simulation Engine director process.

<!-- source-page: 375 -->

# timeout

This option is used to specify a timeout value in seconds for establishing the co-simulation connection using the direct coupling interface or the SIMULIA Co-Simulation Engine. Abaqus terminates if it does not receive any communication from the coupled analysis program during the time specified. The default value is 3600 seconds. The default timeout value that Abaqus uses can be set with the cosimulation\_timeout parameter in the environment file when using the direct coupling interface (see “Using the Abaqus environment settings,” Section 3.3.1).

# Additional option available for the datacheck module

# unconnected\_regions

This option is used to request that Abaqus/Standard create element and node sets for unconnected regions in the analysis output database. Set unconnected\_regions=yes to create element and node sets that are named MESH COMPONENT N, where N is the component number.

# Examples

The following examples illustrate the different functions and capabilities of the abaqus execution procedure.

# Running analyses in Abaqus/Standard

Use the following command to run a heat transfer analysis called “c8” in the background:

abaqus analysis job=c8 background

The following command will run the job c8 in the background and output the current environment settings to the log file:

abaqus analysis job=c8 information=environment background

The follow-up analysis to the heat transfer analysis c8 is “c10,” which is a static analysis that uses temperature data from c8 as input. The temperature data are read in from the c8 results file as predefined fields. The execution procedure scans the Abaqus/Standard input file for file dependencies of this sort. In this example the procedure will look for the c8 results file in the current directory with the extension .fil. The results file identifier can include a path name (see “Input syntax rules,” Section 1.2.1), and the execution procedure will then look in the directory specified. In either case an error message will be issued if the file does not exist. The following command is used to run the job c10 in the “long” queue:

abaqus analysis job=c10 queue=long

This job is next restarted as “c11,” using the final results from c10 as the starting point for a creep analysis. The following command is used to run this job in the default queue:

abaqus analysis job=c11 oldjob=c10 queue=

<!-- source-page: 376 -->

The following command is used to run an Abaqus/Standard analysis called “draw\_imp” that imports the results from a previously run Abaqus/Explicit analysis called “draw\_exp”:

abaqus analysis job=draw\_imp oldjob=draw\_exp

# Running analyses in Abaqus/Explicit

Use the following command to submit an Abaqus/Explicit analysis called “beam” to the default queue:

abaqus analysis job=beam convert=all queue=

Equivalent results would be obtained from the following series of commands:

```txt
abaqus datacheck job=beam interactive
abaqus continue job=beam queue=
abaqus convert=all job=beam interactive 
```

Note that the CPU-intensive analysis option is run in batch, while the other options are run interactively.

# Running analyses in Abaqus/CFD

Use the following command to submit an Abaqus/CFD analysis called “cylinder” using 128 cores in parallel:

abaqus analysis job=cylinder cpus=128

# Running different phases of an analysis

Use the following command to perform a parameter check run on an input file called “parmodel”:

abaqus job=parmodel parametercheck

Use the following command to perform a data check run on an input file called “parmodel” (the parameter check is done again if this job is run after the previous one):

abaqus job=parmodel datacheck

The following command will continue the previous datacheck job to execute the analysis:

abaqus job=parmodel continue

<!-- source-page: 377 -->

# 3.2.3 SIMULIA Co-Simulation Engine DIRECTOR EXECUTION

Products: Abaqus/Standard Abaqus/Explicit Abaqus/CFD

# Reference

• “Execution procedure for Abaqus: overview,” Section 3.1.1

# Overview

Co-simulation between Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD is governed by an additional process, the SIMULIA Co-Simulation Engine (CSE) director. Typically, you are not required to invoke the CSE director process; it is invoked automatically when you run the Abaqus co-simulation procedure (“Abaqus/Standard, Abaqus/Explicit, Abaqus/CFD, AND FMU co-simulation execution,” Section 3.2.4) or if you submit the co-simulation from Abaqus/CAE.

If you are unable to use the Abaqus co-simulation procedure or Abaqus/CAE and are required to submit the co-simulation analyses separately using the Abaqus execution procedure (“Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” Section 3.2.2), you must invoke the CSE director as described in this section.

Command summary 

<table><tr><td>abaqus cse</td><td>job=cosim-job-nameconfigure=configation file-namelistenerport=listener port-number[datacheck][interactive][timeout=timeout value in seconds]</td></tr></table>

# Command line options

# job

The value of this option specifies the name of the co-simulation summary log file generated during the run. If this option is omitted from the command line, you will be prompted for its value.

# configure

This option specifies the name of the SIMULIA Co-Simulation Engine configuration file that governs the co-simulation. For more information, see “Using the SIMULIA Co-Simulation Engine configuration file” in “Preparing an Abaqus analysis for co-simulation,” Section 17.2.1.

<!-- source-page: 378 -->

# listenerport

This option is used to specify the TCP/UDP port number for co-simulation inbound messages to the director. Set listenerport equal to the port number used for the connection.

# datacheck

This option causes the director to check the correctness of the configuration file only.

# interactive

This option causes the director to run interactively.

# timeout

This option is used to specify a timeout value in seconds for the co-simulation director connection. The director terminates if it does not receive any communication from the coupled analysis program during the time specified. The default value is 3600 seconds.

# Example

The following example illustrates the different functions and capabilities of the co-simulation director execution procedure when you are required to submit the co-simulation analyses separately.

# Running an Abaqus/Standard to Abaqus/Explicit co-simulation

Use the following command for the first Abaqus analysis, running on machine “earth,” to connect to the co-simulation director, running on machine “mercury” and listening on port 44444:

abaqus job=explicit csedirector=mercury:44444

Use the following command for the second Abaqus analysis, running on machine “venus,” to connect to the co-simulation director, running on machine “mercury” and listening on port 44444:

abaqus job=standard csedirector=mercury:44444

Use the following command for the co-simulation director, running on machine “mercury,” to operate according to the co-simulation configuration defined in the file explicit\_standard\_config.xml and to receive communication via port 44444:

abaqus cse job=cosim listenerport=44444 configure=explicit\_standard\_config.xml

<!-- source-page: 379 -->

# 3.2.4 Abaqus/Standard, Abaqus/Explicit, Abaqus/CFD, AND FMU CO-SIMULATION EXECUTION

Products: Abaqus/Standard Abaqus/Explicit Abaqus/CFD

# Reference

• “Execution procedure for Abaqus: overview,” Section 3.1.1

# Overview

Co-simulation between Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD, and co-simulation format Functional Mockup Unit (FMU) files can be executed by running the Abaqus co-simulation procedure. Several parameters can be set either on the command line or in the environment file (see “Using the Abaqus environment settings,” Section 3.3.1). See “Co-simulation: overview,” Section 17.1.1, for details about supported co-simulation interactions. Refer to https://www.fmi-standard.org for more information on the Functional Mockup Interface standard.

A co-simulation analysis executes the specified “child” analyses and directs the communication of the processes according to the co-simulation configuration file specifications. The co-simulation execution procedure allows you to enter a single command to run the co-simulation and should be used whenever possible (see “Limitations” below). If you are unable to use the Abaqus co-simulation execution procedure, you are required to do the following:

• submit the co-simulation analyses separately using the Abaqus execution procedure (“Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” Section 3.2.2) or the FMU execution procedure (“SIMULIA Co-Simulation Engine FMU execution,” Section 3.2.6), and   
• invoke the SIMULIA Co-Simulation Engine (CSE) director (“SIMULIA Co-Simulation Engine director execution,” Section 3.2.3).

The co-simulation execution procedure supports a subset of the options that are available for the Abaqus execution procedure; these options are included in the command summary below.

# Composition of command line arguments

You can use comma-separated lists of options for command line arguments for the participating child analyses. Command line arguments (see the command line options below) are categorized as either

• global options, taking a single argument;   
• applicable to Abaqus child analyses, taking a comma-separated list whose length is the number of participating Abaqus jobs; or   
• applicable to FMUs, taking a comma-separated list whose length is the number of participating FMUs.

Therefore, the length of command line argument lists generally varies for co-simulation analyses that use Abaqus products and FMUs.

<!-- source-page: 380 -->

Your CPU allocation specification applies to Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD child jobs. Functional Mockup Units (FMUs) do not support multiple-CPU use. Three methods are available for allocating CPUs to child analysis jobs for parallel processing: specifying the number of CPUs for each job, distributing CPUs between analysis jobs, and distributing CPUs between analysis products.

# Specifying the number of CPUs for each job

The most direct method of allocating CPUs is to specify the number of CPUs to be used for each child analysis. You provide a comma-separated list of values using the cpus parameter.

# Distributing CPUs between analysis jobs

You can specify the total number of CPUs to be used for your co-simulation analysis and weighting factors that determine the distribution of the CPUs between the child analyses. This method enables you to specify a CPU count that relates directly to your resource limits and to describe the relative computational needs of the child analyses. You provide one value for the number of CPUs to allocate for the co-simulation using the cpus parameter, and you define weight factors using the cpuratio parameter.

Weight factors are floating point numbers and are considered in a normalized sense. For example, if you wish to specify that the CPU allocation for the first child job is four times that of the second job, you can provide any of the following pairings:

```csv
cpuratio=4.0,1.0
cpuratio=16,4
cpuratio=0.8,0.2 
```

# Distributing CPUs between analysis products

You can specify the total number of CPUs to be used for your co-simulation analysis and weighting factors that determine the distribution of the CPUs between the analysis products involved in the co-simulation. This method enables you to specify a CPU count that relates directly to your resource limits and to describe the relative computational needs of the child analyses based on the analysis product used (Abaqus/Standard, Abaqus/Explicit, or Abaqus/CFD). You provide one value for the number of CPUs to allocate for the co-simulation using the cpus parameter, and you define weight factors in the environment file using the cpus\_weight\_std, cpus\_weight\_xpl, and cpus\_weight\_cfd environment variable parameters (see “Co-simulation parameters” in “Using the Abaqus environment settings,” Section 3.3.1).

Weight factors are interpreted in a normalized sense. For example, if you wish to specify that the CPU allocation for the Abaqus/CFD analysis is twice that of the Abaqus/Explicit analysis, you define the parameters in the environment file as follows:

```ini
cpus_weight_xpl=1
cpus_weight_cfd=2 
```
