Preparing an Abaqus Analysis for Co-Simulation

Identifying an Abaqus Step for Co-Simulation Analysis

The co-simulation event need not begin at the start of the first step in an Abaqus analysis. However, it does need to start with the beginning of an analysis step and end within that analysis step. Hence, you need to define the step durations in Abaqus such that the start of the co-simulation event falls at the beginning of an Abaqus analysis step and to define that particular step so that the co-simulation event ends by the end of that step. Regular loads and boundary conditions for the Abaqus model are specified as usual.

Communication with the coupled analysis is initiated as the co-simulation event begins and is terminated when the co-simulation event time is reached. Abaqus might terminate the co-simulation event when the end of the analysis step is reached before the co-simulation event time or when the analysis cannot proceed any further; for example, because of convergence problems. In such a case, a warning message is issued to all clients, and the co-simulation is terminated.

Co-simulation is supported by the following Abaqus procedures:

Input File Usage

Use the following option within a step definition to indicate the beginning of a co-simulation event:

CO-SIMULATION, NAME=name

Identifying the Analysis Program Communicating with Abaqus during the Co-Simulation

You can couple Abaqus with another Abaqus analysis or Abaqus with certain third-party analysis programs using the SIMULIA Co-Simulation Engine. For details on coupling with third-party analysis programs, see the respective User's Guides.

Input File Usage

Use the following option to couple Abaqus analyses (except Abaqus/Standard to Abaqus/Explicit) and Abaqus to third-party analysis programs:

CO-SIMULATION, NAME=name, PROGRAM=MULTIPHYSICS

Use the following option to couple Abaqus/Standard to Abaqus/Explicit:

CO-SIMULATION, NAME=name, PROGRAM=ABAQUS

Identifying the Co-Simulation Interface Region

Interaction between two Abaqus models or between an Abaqus model and a third-party analysis model takes place through a common interface region referred to as the co-simulation interface region. The co-simulation interface region can be a set of discrete points, a surface region, or a volume region. You must be consistent in your interface region definition; if you define a surface co-simulation region in one analysis, then you must define a surface co-simulation region in the other analysis. Furthermore, these co-simulation regions need to be co-located and have the same region boundaries.

Interacting through Discrete Points

Interaction can occur through a set of discrete points where only nodal position information without element topology information (for example, tributary area) defines the co-simulation interface region. In this case the spatial mapping is limited to point-to-point mapping, and you must ensure that there are matching nodes between the models.

In Abaqus you can use a node set or a node-based surface to define a co-simulation interface region consisting of discrete points.

Input File Usage

Use the following option to define a node set as a co-simulation region in an Abaqus model:

CO-SIMULATION REGION, TYPE=NODE
nodeset_A

Use the following options to define a node-based surface as a co-simulation region in an Abaqus model:

SURFACE, TYPE=NODE
nodeset_A
CO-SIMULATION REGION, TYPE=SURFACE
node-based surface name

Interacting through a Surface

Interaction between distinct domains occurs through a common interface surface. For example, when a fluid interacts with a solid without penetrating it, the fluid-solid interface is defined through a surface. In this case both nodal position and element topology information define the co-simulation interface, and appropriate spatial mapping between dissimilar surface meshes is performed to conservatively map fields.

Input File Usage

Use the following option to define an element-based surface as a co-simulation region in an Abaqus model:

CO-SIMULATION REGION, TYPE=SURFACE (default)
element-based surface name

Interacting through a Volume

Interaction between overlapping domains occurs through a volume. In this case both nodal position and element topology information define the co-simulation region, and appropriate spatial mapping between dissimilar volume meshes is performed to conservatively map fields.

The interface region is defined by an element set.

Input File Usage

Use the following option to define a volume as a co-simulation region in an Abaqus model:

CO-SIMULATION REGION, TYPE=VOLUME
elset_A

Identifying the Fields Exchanged across a Co-Simulation Interface

The coupling of the domain models can be through loads and/or boundary conditions prescribed at the co-simulation interface. In addition, mass, rotary inertia, and heat capacitance terms can also be exchanged. Based on the physics and the interaction type and its enforcement, you must specify the fields that are imported and/or exported in an Abaqus analysis during the co-simulation.

The co-simulation interface can consist of a group of discrete points (nodes), a surface region, or a volume region. Not all fields can be exchanged across all region types.

This section provides a general overview of all fields available in Abaqus. For detailed information on the fields exchanged between two Abaqus solvers, see Structural-to-Structural Co-Simulation. For detailed information on fields exchanged by Abaqus and a third-party analysis program, see the respective User’s Guides.

Input File Usage

Use the following option to import field data over a region into Abaqus:

CO-SIMULATION REGION, IMPORT
region_A, import_field_1
region_A, import_field_2

Use the following option to export data from Abaqus:

CO-SIMULATION REGION, EXPORT
region_A, export_field_1
region_A, export_field_2

Procedures Involving Mechanical Degrees of Freedom

Table 1 lists the fields that can be exchanged for procedures supporting mechanical degrees of freedom (degrees of freedom 1–6), their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 1. Exchanging fields for procedures supporting mechanical degrees of freedom.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
UT or U	Displacement	P, S, V	S, E	S, E	L
VT or V	Velocity (transient procedures)	P, S, V	S, E	S, E	$L T^{- 1}$
AT or A	Acceleration (transient procedures)	P, S, V	S	S, E	$L T^{- 2}$
UR	Rotations	P, S	S, E	S, E	radians
VR	Angular velocity (transient procedures)	P, S	S, E	S, E	radians $T^{- 1}$
AR	Angular acceleration (transient procedures)	P, S	S	S, E	radians $T^{- 2}$
COORD	Current coordinates	P, S, V		S, E
CF	Concentrated forces	P, S, V	S, E	S, E	F
CM	Concentrated moments	P, S	S, E	S, E	$F L$
P	Pressure normal to element surface	S	S		$F L^{- 2}$
TRVEC	Traction vector	S	S		$F L^{- 2}$
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

The following procedures support co-simulation using mechanical degrees of freedom:

Displacements

Displacements (field ID UT or U) for the translational degrees of freedom can be exported by Abaqus/Standard and Abaqus/Explicit. Displacements can be imported by Abaqus/Standard and Abaqus/Explicit. When imported, displacements are ramped from the values of the previous exchange time point to those of the next target time point. In an implicit dynamic analysis, velocity and acceleration must be imported when importing displacement. The displacements are in the global coordinate system.

Displacements are available for points, surface regions, and volume regions in Abaqus/Standard and Abaqus/Explicit.

Displacements can be viewed in the Visualization module of Abaqus/CAE.

Velocity and Acceleration

Velocity (field ID VT or V) and acceleration (field ID AT or A) for the translational degrees of freedom can be imported and exported by Abaqus/Standard for transient procedures and by Abaqus/Explicit. In an implicit dynamic analysis, when importing velocity or acceleration, all three fields—displacement, velocity, and acceleration—must be imported. Velocity and acceleration are in the global coordinate system.

Velocity and acceleration are available for points, surface regions, and volume regions in Abaqus/Standard and Abaqus/Explicit.

Rotations

Rotations (field ID UR) can be imported and exported by Abaqus/Standard and Abaqus/Explicit. In an implicit dynamic analysis, rotational velocity and rotational acceleration must be imported when importing rotations. Rotations are in the global coordinate system.

Rotations are available for points and surface regions.

Rotations can be viewed in the Visualization module of Abaqus/CAE.

Rotational Velocity and Rotational Acceleration

Rotational velocity (field ID VR) and rotational acceleration (field ID AR) can be imported and exported by Abaqus/Standard for transient procedures and by Abaqus/Explicit. In an implicit dynamic analysis, when importing rotational velocity or rotational acceleration, all three fields—rotation, rotational velocity, and rotational acceleration—must be imported. Rotational velocity and rotational acceleration are in the global coordinate system.

Rotational velocity and rotational acceleration are available for points and surface regions.

Current Coordinates

Current nodal coordinates (field ID COORD) can be exported by Abaqus/Standard and Abaqus/Explicit. The coordinates are the current coordinates of the deformed structure whether small- or large-displacement analysis is performed. In general, it is preferred to export displacements (field ID UT or U) rather than current coordinates when results are mapped between dissimilar interface regions. In cases where the partner client does not retain the original coordinates, it might be necessary to send current coordinate values rather than displacements.

Current coordinates are available for points, surface regions, and volume regions in Abaqus/Standard and Abaqus/Explicit.

Concentrated Forces

Concentrated forces (field ID CF), if imported, are ramped from the values of the previous exchange time point to those of the next target time point in Abaqus/Standard and are kept constant over the exchange interval in Abaqus/Explicit. The concentrated forces are in the global coordinate system.

When exporting concentrated forces, Abaqus/Standard transfers reaction forces at interface nodes that have prescribed displacements. The reaction forces are exported in the global coordinate system.

Concentrated forces are available for points, surface regions, and volume regions in Abaqus/Standard and Abaqus/Explicit.

Concentrated normal forces can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable CF.

Concentrated Moments

Concentrated moments (field ID CM), if imported, are ramped from the values of the previous exchange time point to those of the next target time point in Abaqus/Standard and are kept constant over the exchange interval in Abaqus/Explicit. The concentrated moments are in the global coordinate system.

Concentrated moments are available for points and surface regions in Abaqus/Standard and Abaqus/Explicit.

Concentrated moments can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable CM.

Normal Pressure

Normal pressure (field ID P), supported for import by Abaqus/Standard, is the traction normal component to the surface. Pressure values are ramped from the values of the previous exchange time point to those of the next target time point when imported into Abaqus/Standard. In most cases it is preferred to import concentrated forces (field ID CF) because these contain both the normal and shear traction components. For shell and membrane-like structures, it might be preferable to import pressures rather than concentrated forces.

Normal pressure can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable P.

Traction Vector

Traction vector (field ID TRVEC), supported for import by Abaqus/Standard, is a general traction vector acting on a surface. Traction values are ramped from the values of the previous exchange time point to those of the next target time point when imported into Abaqus/Standard. For shell and membrane-like structures, it might be preferable to import traction rather than concentrated forces.

Normal pressure can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable P.

Procedures Involving Thermal Degrees of Freedom

Table 2 lists the thermal fields available for co-simulation exchange, their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 2. Exchanging fields for procedures supporting thermal degrees of freedom.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
NT	Nodal temperature	P, S, V	S, E	S, E	$θ$
CFL	Concentrated heat flux at a node	P, S, V	S, E		$J T^{- 1}$
HFL	Heat flux normal to element surface	S	S		$J T^{- 1} L^{- 2}$
FILM	Film properties	S	S		$J T^{- 1} L^{- 2} θ^{- 1}$
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

The following procedures support co-simulation using thermal degrees of freedom:

Nodal Temperature

Nodal temperature (field ID NT) can be imported and exported by Abaqus/Standard and Abaqus/Explicit. Temperature values are ramped from the values of the previous exchange time point to those of the next target time point when imported into Abaqus/Standard.

Temperature values can be exchanged either on the top surface (SPOS) or the bottom surface (SNEG) of structural elements. Temperatures cannot be exchanged on double-sided surfaces. When exchanging temperatures on both the top and bottom faces, define two different regions; one to exchange temperature on the top face and the other to exchange temperature on the bottom face.

Nodal temperature values can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable NT.

Heat Flux

Use concentrated heat flux (field ID CFL) for heat entering at a node in Abaqus/Standard and Abaqus/Explicit. Concentrated heat flux is available for points, surface regions, and volume regions.

Heat flux values can be exchanged either on the top surface (SPOS) or the bottom surface (SNEG) of structural elements. Heat flux cannot be exchanged on double-sided surfaces. When exchanging heat flux on both the top and bottom faces, define two different regions; one to exchange heat flux on the top face and the other to exchange heat flux on the bottom face.

Concentrated heat flux values can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable CFL.

Use surface heat flux (field ID HFL) for a distributed heat flux entering the surface in Abaqus/Standard. Distributed heat flux is available only for surface regions.

Surface heat flux can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable FLUXS.

Film Properties

Use surface film properties (field ID FILM) to model convection governed by

q = - h (θ_{w a l l} - θ_{f l u i d}),

where q is the heat flux entering the surface, h is a film coefficient, $θ_{w a l l}$ is the wall temperature, and $θ_{f l u i d}$ is the fluid or ambient temperature.

Both the film coefficient and fluid temperature are passed into Abaqus/Standard and are kept constant over the subsequent exchange interval. When the fluid and wall temperatures coincide, an arbitrary small value for the heat transfer coefficient is passed into Abaqus. To obtain reasonable film properties for the first exchange interval, you should ensure that the wall temperatures are initialized properly in Abaqus and that you provide a good estimate for the initial fluid temperature.

Film properties are available only for surface regions in Abaqus/Standard.

Procedures Involving Pore Fluid Pressure

Table 3 lists additional fields that can be exchanged for a coupled pore fluid diffusion/stress analysis, their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 3. Exchanging fields for a coupled pore fluid diffusion/stress analysis.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
POR	Pore fluid pressure at a node	P, S, V	S	S	$F L^{- 2}$
CFF	Concentrated fluid flow at a node	P, S, V	S		$L^{3} T^{- 1}$
RVF	Reaction fluid volume flux due to prescribed pressure	P, S, V		S	$L^{3} T^{- 1}$
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

The following procedure involving pore fluid pressure supports co-simulation:

Coupled Pore Fluid Diffusion and Stress Analysis

Pore Pressure

Nodal pore pressure (field ID POR) can be imported and exported by Abaqus/Standard for points, surface regions, and volume regions.

Nodal pore pressure values can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable POR.

Concentrated Fluid Flow

Fluid flow (field ID CFF) defines the seepage flow at a node. Concentrated fluid flow can be imported by Abaqus/Standard for points, surface regions, and volume regions.

Concentrated fluid flow values can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable CFF.

Reaction Fluid Volume Flow

Reaction fluid volume flux (field ID RVF) defines the rate at which fluid volume is entering or leaving the model through the node to maintain the prescribed pore pressure. Reaction fluid volume flux can be exported by Abaqus/Standard for points, surface regions, and volume regions.

Procedures Involving Electromagnetic Response

Table 4 lists additional fields that can be exchanged for an electromagnetic analysis, their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 4. Exchanging fields for a electromagnetic analysis.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
EMJH	Joule heating flux due to flow of current	V		S	$J T^{- 1} L^{- 3}$
EMBF	Magnetic body force intensity vector due to flow of induced current	V		S	$F T^{- 1} L^{- 3}$
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

The following procedure involving electromagnetics supports co-simulation:

Eddy Current Analysis

Joule Heating Flux

The Joule heating flux (field ID EMJH) can be exported by Abaqus/Standard for volume regions. It can be imported in a downstream heat transfer analysis as concentrated nodal heat flux (field ID CFL).

Values for the Joule heating flux can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable EMJH.

Magnetic Body Force Intensity Vector

The magnetic body force intensity vector (field ID EMBF) can be exported by Abaqus/Standard for volume regions. It can be imported in a downstream stress analysis as concentrated force (field ID CF).

Magnetic body force intensity vector values can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation by requesting output variable EMBF.

Temperature and Independent Field Variables

Field variables are time-dependent, predefined fields that exist over the spatial domain of the model (see Predefined Fields). Field variables in conjunction with the co-simulation technique extend the possibilities of multiphysics by allowing material point dependencies on an external field defined by another application.

Field variables must be numbered consecutively starting with one. Field variables can be defined:

by entering the data directly,
by reading an Abaqus results file or output database file,
in an Abaqus/Standard user subroutine, and
through the co-simulation interface.

If field variables are defined by multiple methods, Abaqus processes them in the order defined above. Care needs be taken when field variables are used with structural elements, such as membranes and shells. In this case only the top or bottom face forming the interface region receives a value.

Table 5 lists the temperature and independent field variables available for co-simulation exchange, their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 5. Exchanging temperature and independent field variables.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
NT	Temperature as field variable specified at nodes but interpolated to integration points	V	S		$θ$
FV1	Field variable 1	V	S
FV2	Field variable 2	V	S
FV3	Field variable 3	V	S
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

The following Abaqus/Standard procedures support import of temperature and independent field variables:

Temperature as a Field and Field Variables

Temperature (field ID NT) can be imported by Abaqus/Standard for procedures that allow material properties to be defined as a function of an external temperature field. When imported, temperature values are ramped from the values of the previous exchange time point to those of the next target time point.

Independent field variables (field IDs FV1, FV2, and FV3) can be imported by Abaqus/Standard, allowing material properties to be defined as a function of the external fields. When imported, independent field variable values are ramped from the values of the previous exchange time point to those of the next target time point.

Temperature as a field variable can be viewed in the Visualization module of Abaqus/CAE for an Abaqus/Standard simulation. You might notice differences when you compare the source and target fields. There are two possible causes for these differences:

Field variables and temperature as a field variable are mapped accurately and imported at nodes. However, when saved to the output database, these quantities are interpolated to element integration points. When contouring, some averaging can occur depending on the contouring parameters selected.
For fully integrated first-order elements, a selective reduced-integration technique is employed (see Solid isoparametric quadrilaterals and hexahedra). In this case, field variables and temperature as a field variable are averaged at the element center and saved to the output database.

Miscellaneous Fields

Table 6 lists miscellaneous fields available for co-simulation exchange, their associated field identifiers, the supported co-simulation interface region types, and which Abaqus solvers support import and export of the field values.

Table 6. Exchanging miscellaneous fields.
Field ID	Fields	Interface Type¹	Abaqus Solver²		Units
Field ID	Fields	Interface Type¹	Import	Export	Units
MASS or LUMPEDMASS	Mass	P, S	S, E	S, E	M
RI	Rotary inertia	P, S	S	E	$M L^{2}$
¹ P (points), S (surface region), V (volume region)
² S (Abaqus/Standard), E (Abaqus/Explicit)

Lumped Mass

Lumped mass values (field ID MASS or LUMPEDMASS) at nodes can be exported and imported by Abaqus/Standard and Abaqus/Explicit.

Lumped mass is available for points and surface regions.

Rotary Inertia

Nodal (lumped) rotary inertia (field IDRI) can be imported by Abaqus/Standard and exported by Abaqus/Explicit over points or surface regions for models using structural elements.

Defining the Coupling and Rendezvousing Scheme

Different types of analyses have different time integration requirements that influence or dictate the frequency of interaction between the analyses in a co-simulation to obtain an accurate and robust solution. For example, consider the difference in time integration between an implicit and an explicit dynamic analysis. Furthermore, Abaqus/Standard can adjust the increment sizes automatically to obtain an economical and accurate solution for transient problems (see Incrementation). For example, consider a transient heat transfer analysis modeling a diffusive process. Here, the analysis might use small time increments at the beginning of the analysis where there is a high gradient in the solution and large time increments toward the end of the analysis when steady state is reached.

The parameters that you use to control these co-simulation exchanges depend on the co-simulation interface that you are using.

You define the co-simulation algorithm and related exchange parameters in a co-simulation configuration file.
For structural-to-structural co-simulation using Abaqus/Standard and Abaqus/Explicit, you must also provide co-simulation controls parameters in the input file.

Using the SIMULIA Co-Simulation Engine Configuration File

The SIMULIA Co-Simulation Engine employs an independent software component, termed the “director,” which defines all aspects of the interaction for co-simulation between analysis programs and provides the necessary instructions to implement the coupling and rendezvousing schemes. You provide the director with relevant parameters for your scheme choices through the co-simulation configuration file. When you use Abaqus/CAE to execute the co-simulation, the configuration file is created for you automatically.

The configuration file must be in Extensible Markup Language (XML) format, which uses the file extension xml. You can define a configuration file through a predefined template, or you can create a fully elaborated form of the configuration file.

Using predefined configuration templates

For the co-simulation analysis cases described in Co-Simulation between Abaqus Solvers, predefined templates that define common coupling and rendezvousing schemes are available. To use one of the predefined templates, you must create a configuration file with the structure shown below.

<?xml version="1.0" encoding="utf-8"?>
Required XML declaration line
<CoupledMultiphysicsSimulation>
Required XML root element; identifies file as describing a multiphysics simulation
   <template_name>
      <template_parameter_1>parameter_1_name</template_parameter_1>
      <template_parameter_2>parameter_2_name</template_parameter_2>
      <template_parameter_3>parameter_3_name</template_parameter_3>
   </template_name>
   Closure of the template element
</CoupledMultiphysicsSimulation>
Closure of the XML root element

You enter the template name and a short list of parameter settings, such as the names of the two analysis jobs and the duration of the analysis. Details of the predefined templates are provided in Structural-to-Structural Co-Simulation and Electromagnetic-to-Structural and Electromagnetic-to-Thermal Co-Simulation, as well as information on how to obtain an example configuration file for each template.

Using Elaborated Configuration Files

At run time, the SIMULIA Co-Simulation Engine director applies your parameter settings to the template, creating an elaborated configuration file that is then used in the co-simulation analysis. An elaborated configuration file is defined as a configuration file that provides all details of the configuration explicitly without referring to a template.

In cases where predefined templates are not available (such as coupling with an in-house or third-party code) or are insufficient (for example, you want to exchange more variables at the co-simulation interface region or adjust mapping tolerances), you must create an elaborated configuration file. For tips on working with elaborated configuration files, see “Advanced Uses of the SIMULIA Co-Simulation Engine Configuration File” in the Dassault Systèmes Knowledge Base at https://support.3ds.com/knowledge-base/. For detailed information about the elaborated configuration file, see the SIMULIA Co-Simulation Engine Application Programing Interface (API) documentation.

Coupling and Rendezvousing Schemes for Elaborated Configuration Files

You define the co-simulation coupling and rendezvousing schemes in an elaborated configuration file.

Coupling Scheme

The coupling scheme defines the sequence of exchanges between analysis programs and whether a coupled simulation can be run in a serial, parallel, or implicit iterative manner. When deciding on the coupling scheme, you should consider solution stability issues as well as the utilization impact on your computing resources

Parallel Explicit Coupling Scheme (Jacobi)

In a parallel explicit coupling scheme, both simulations are executed concurrently, exchanging fields to update the respective solutions at the next target time. The parallel coupling scheme might make more efficient use of computing resources; however, it is considered less stable than the sequential scheme and should be employed only for weakly coupled physics simulations using small coupling steps.

Sequential Explicit Coupling Scheme (Gauss-Seidel)

In a sequential explicit coupling scheme, the simulations are executed in sequential order. One analysis leads while the other analysis lags the co-simulation.

The sequential explicit coupling scheme should be employed only for weakly coupled physics simulations using small coupling steps.

Iterative Coupling Scheme

In an iterative coupling scheme, the simulations are executed in sequential order. One analysis leads while the other analysis lags the co-simulation. Multiple exchanges per coupling step are performed until termination criteria are met.

The termination criteria depend on the analyses in the co-simulation; for co-simulation between Abaqus and third-party analysis products, consult the appropriate User’s Guide.

Coupling Step Size

The coupling step is the period between two consecutive exchanges and consequently defines the frequency of exchange between the analyses in a co-simulation. The coupling step size is established at the beginning of each coupling step and is used to compute the target time (the time when the next synchronized exchange occurs).

The methods available in Abaqus for computing the coupling step size are described in the sections below. To determine the methods available for a co-simulation partner analysis, consult the appropriate third-party program documentation.

Constant Coupling Step Size

A constant user-defined coupling step size is the most basic method of defining a coupling step size. Both analyses advance while exchanging data at target points according to

t_{i + 1} = t_{i} + Δ t_{c},

where $Δ t_{c}$ is a value that defines the coupling step size to be used throughout the coupled simulation, $t_{i + 1}$ is the target time, and $t_{i}$ is the time at the start of the coupling step.

Minimum Coupling Step Size

This method selects the minimum of the coupling step sizes suggested by each analysis. Abaqus always uses the next increment suggested by its automatic incrementation as its suggested coupling step size.

Maximum Coupling Step Size

This method selects the maximum of the coupling step sizes suggested by each analysis. Abaqus always uses the next increment suggested by its automatic incrementation as its suggested coupling step size.

Importing the Coupling Step Size

Abaqus can import a coupling step size suggested by the co-simulation partner analysis.

Exporting the Coupling Step Size

Abaqus can export a suggested coupling step size to the co-simulation partner analysis.

Time Incrementation Scheme

Abaqus might take multiple increments per coupling step, or you can force Abaqus to use a single increment per coupling step.

Typically, Abaqus might perform several increments (referred to as “subcycling”) during the coupling step. During subcycling, Abaqus/Standard ramps the loads and boundary conditions (with the exception of film properties) from the values at the end of the previous coupling step to the values at the target time, while in Abaqus/Explicit the loads are applied at the start of the coupling step and kept constant over the coupling step.

Subcycling allows Abaqus to use its own time incrementation to reach the target coupling time; specifically, it allows Abaqus to cut back the increment size if there are nonlinear events that require the increment size to be reduced.

In certain cases you can force Abaqus to use a time increment size dictated by the coupling step size (that is, no subcycling). This allows both solvers to use the same time incrementation and avoid interpolation of quantities during the coupling step. When proceeding in this “lockstep” manner, Abaqus is not able to reduce the time increment to resolve nonlinear events and, consequently, ends the simulation in cases where the nonlinear events require that the increment size be reduced.

Model Dimension and Coordinate Systems

Two-dimensional and three-dimensional Abaqus models are fully supported. Axisymmetric Abaqus models are supported only for Abaqus/Standard to Abaqus/Explicit co-simulation. For co-simulations that do not support two-dimensional and axisymmetric models, you can represent these models as a three-dimensional slice of unit thickness (or wedge element) with the appropriate boundary conditions applied.

Vector quantities are defined according to Abaqus conventions; the first component represents the quantity along the x-axis, the second quantity represents the quantity along the y-axis, and the third quantity represents the quantity along the $z$ -axis (for three-dimensional models). For axisymmetric models in Abaqus the axis of revolution is about the y-axis. These conventions apply to both the exported and the imported vector quantities.

All exported vector quantities are expressed in the global coordinate system of the Abaqus model, ignoring any transformation definitions. Similarly, the third-party program must provide vector quantities that are imported into Abaqus in the global coordinate system of the Abaqus model.

The third-party analysis program might use different conventions, please refer to the appropriate third-party program documentation for further modeling details and/or limitations.

Unit System

Abaqus does not require that the analysis be run with a particular unit system. In general, the unit system used in creating the Abaqus model might not be the same as that used with the third-party program model. When the two unit systems differ, the fields exchanged between the two programs must go through a transformation of units. Refer to the appropriate third-party program documentation for further modeling details.

Restarting a Co-Simulation

Restart output must be synchronized between co-simulation analyses for a co-simulation restart to be successful. You should request that restart data are written at the co-simulation target times when both solutions are considered at equilibrium. For more information, see Synchronizing Restart Information Written in a Co-Simulation. The solution time for the particular step/increment number from which Abaqus restarts must correspond to the coupled analysis solution.

Limitations

The following limitations apply:

The steps in the Abaqus model must be defined such that the co-simulation fits entirely within a single Abaqus step. Further, there can be only one co-simulation in the Abaqus job. You can use the restart capability to perform multiple co-simulations for an analysis (see Restarting an Analysis).
A co-simulation surface or volume defined over beam, pipe, and truss elements or defined over the edges of three-dimensional elements cannot be used as an interface region. You should use discrete points to transfer loads and boundary conditions.
A co-simulation surface or volume defined over modified triangular elements or modified tetrahedral elements cannot be used as an interface region.
Quadratic coupled temperature-displacement elements cannot be used as an interface region in a co-simulation using the coupled temperature-displacement procedure.
When performing a co-simulation, output at specified time points might not be satisfied at the requested times, depending on the synchronization parameters.

Because co-simulation is a general capability, no error message is issued if Abaqus encounters the conditions listed above. There might be further limitations depending on the third-party analysis program being used. For more information, refer to the appropriate third-party program documentation.