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,PROGRAM=MULTIPHYSICS

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 (see Domain Coupling for Multiphysics and Multiscale Simulations). You must be consistent in your interface region definition; if you define a surface co-simulation region in one analysis, you must define a surface co-simulation region in the other analysis. In addition, these co-simulation regions need to be colocated and have the same region boundaries. The regions should not overlap unless different physics interactions are transferred.

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. Interaction through discrete points is commonly employed when coupling Abaqus with a one-dimensional model.

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 common 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 intersecting both numerical domains. Typical examples of volumetric interaction include coupling Abaqus with an electromagnetic solver and Abaqus with a reservoir solver. 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 conservatively.

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. For example, pressure (that is, force per unit area) is a surface quantity, and it cannot be transferred at discrete points or over a volume.

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	L
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. 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. 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.

Velocity and acceleration can be viewed in the Visualization module of Abaqus/CAE.

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 radians and 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. Rotational velocity and acceleration are in radians per time and time squared, respectively, and are in the global coordinate system.

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

Rotational velocity and acceleration can be viewed in the Visualization module of Abaqus/CAE.

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. 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 and for Abaqus/Explicit simulation by requesting output variable FEXT.

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. 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 and for an Abaqus/Explicit simulation by requesting output variable MEXT.

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}$
FILMCOEF	Film properties	S	S		$J T^{- 1} L^{- 2} θ^{- 1}$
SINKTEMP	Sink temperature	S	S		$θ$
¹ 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.

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. Temperatures cannot be exchanged through the volume of a shell element.

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. Heat flux cannot be exchanged through the volume of shell elements.

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 FILMCOEF and SINKTEMP) 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 sink temperature.

Both the film coefficient and fluid temperature need to be imported 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 heat flux for the first exchange interval, you need to 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 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 Algorithm

The coupling algorithm defines the sequence of exchanges between the analysis programs and any special interface calculations that are performed on the interface. When deciding on the coupling algorithm, you should consider solution stability issues as well as the utilization impact on your computing resources. The SIMULIA Co-Simulation Engine overs a wide choice of coupling algorithms (see Strength of Physics Coupling and Coupling Algorithms) including explicit schemes, implicit iterative schemes with a choice of accelerators, and specialized coupling algorithms (for Abaqus/Standard to Abaqus/Explicit or Abaqus to Simpack co-simulation). The choice of the coupling scheme also depends on the solvers participating in the co-simulation; for example, you cannot use implicit iterative coupling if one of the solvers uses explicit time integration. Consideration should also include the numerical cost associated with interface computations; for example, the enhanced sub-cycling method can become excessively costly for large interfaces, and the Quasi-Newton accelerators might be too expensive when coupling large volumetric domains.

The coupling algorithm and its associated parameters are defined in the SIMULIA Co-Simulation Engine configuration file. For guidance in selecting an appropriate coupling algorithm for co-simulation between Abaqus solvers, see Co-Simulation between Abaqus Solvers; for co-simulation between Abaqus and third-party analysis programs, consult the appropriate user’s guide.

Explicit Coupling Schemes

In an explicit staggered approach fields are exchanged once per coupling step, and no convergence check is performed before the solvers advance to the next coupling step. You should employ the explicit staggered approach when one of the solvers uses explicit time integration or for weak to moderate physics coupling (for example, aeroelasticity problems where you have air interacting with a relatively stiff structure). The explicit staggered approach is numerically cost effective, but it requires the use of a smaller coupling step size to obtain a stable and accurate solution.

The solvers can be executed in parallel (commonly referred to as the Jacobi scheme) or sequentially (commonly referred to as the Gauss-Seidel scheme). In the Jacobi scheme, both solvers execute at the same time and both solutions lag by one coupling step. The Jacobi scheme might make more efficient use of computing resources; however, it is considered less stable than the Gauss-Seidel scheme. In the Gauss-Seidel scheme, the simulations are executed in sequential order; and one analysis leads while the other analysis lags the co-simulation.

Implicit Iterative Coupling Schemes

In an implicit iterative coupling scheme, the simulations are executed in sequential order. When commencing a coupling step, one analysis leads while the other analysis lags the co-simulation. However, multiple exchanges (referred to coupling iterations) are performed at the target point until global convergence (convergence between all solvers) is achieved, prior to commencing the next coupling step. The additional coupling iterations remove the lag between the solutions that exists for explicit coupling.

Implicit coupling is numerically more costly because multiple coupling iterations are performed; however, in general, a larger coupling step size can be used to obtain a stable solution. You should use implicit coupling for strong physics coupling if all solvers use implicit time integration.

Accelerators for the implicit iterative schemes enhance the coupling by enlarging the convergence radius from a stability point of view. The SIMULIA Co-Simulation Engine supports two types of accelerator methods:

Relaxation is a numerical technique employed commonly to improve the stability of a computation. Using a relaxation factor less than one improves the stability at the expense of slower convergence (more coupling iterations). Relaxation works well for moderate-strength physics coupling.
The Quasi-Newton methods approximate an inverse Jacobian at the interface and can deliver close to an exact inverse Jacobian if sufficient past residual information is available. The Quasi-Newton method incurs an interface cost but can significantly reduce the number of coupling iterations. It is best suited for strongly coupled physics.

Specialized Coupling Schemes

The SIMULIA Co-Simulation Engine supports specialized coupling schemes through communication of “right-hand-side” and “left-hand-side” terms to provide robust interface solutions, which support coupling of solvers that use different time integration schemes (for example, explicit versus implicit time integrators). These coupling scheme provide robust and cost effective solutions and are employed for coupling Abaqus/Standard to Abaqus/Explicit or Abaqus to Simpack.

Rendezvousing Schemes

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 increment size between an implicit and an explicit dynamic analysis. In addition, 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 coupling step is the period between two consecutive exchanges. Consequently, it defines the frequency of exchange between the analyses in a co-simulation and directly influences the stability and accuracy of the coupled solution. The coupling step size is established at the beginning of each coupling step and is used to compute the next target time (the time when the next synchronized exchange of field data occurs). The SIMULIA Co-Simulation Engine determines the next coupling step's size based on the analyses' preferred increment size and the user-selected negotiation scheme. Abaqus always uses the increment size suggested by its automatic time incrementation as the preferred increment size for determining the coupling step size.

Typically, Abaqus might perform several increments (referred to as “subcycling”) during the coupling step. During subcycling, Abaqus ramps the loads and boundary conditions from the values at the end of the previous coupling step to the values at the target time. 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. However, subcycling might come at the expense of solution robustness and accuracy.

In certain cases you can force Abaqus to use a time increment size equal to the coupling step size (referred to as lockstep). This approach allows both solvers to use the same time incrementation and avoid interpolation of quantities during the coupling step. It is best from a solution robustness and accuracy point of view. 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. In most cases it is best to subcycle and take a penalty in terms of solution robustness and accuracy. 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.

The SIMULIA Co-Simulation Engine provides multiple negotiation methods as described below.

Constant Coupling Step Size

A constant user-defined coupling step size is used to determine the next coupling step size. In this case, the solver's preferred solver coupling step sizes are ignored. All 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. This strategy is simple; however, it is not ideal when the individual solvers adapt their increment sizes for stability and accuracy.

Minimum Coupling Step Size

This method selects the minimum of the preferred step sizes suggested by each analysis. The minimum method cannot be used in a co-simulation involving Abaqus/Explicit.

Maximum Coupling Step Size

This method selects the maximum of the preferred step sizes suggested by each analysis.

Having a Solver Dictate the Coupling Step Size

In this method a designated solver specifies the coupling size; Abaqus ignores the other solver's preferred coupling step sizes. You can use this method only with Abaqus/Explicit and only when Abaqus/Explicit dictates the coupling step size.

Constant Multiple

This method is similar to the constant coupling step size method, except that the coupling step size is dictated by one of the solvers at the start of the analysis. In addition, the other clients' preferred step size is used to determine the constant multiple of the dictated coupling step size.

The rendezvousing scheme and its associated parameters are defined in the SIMULIA Co-Simulation Engine configuration file. For guidance in selecting an appropriate rendezvousing scheme for co-simulation between Abaqus solvers, see Co-Simulation between Abaqus Solvers. For co-simulation between Abaqus and third-party analysis programs, see the appropriate user’s guide.

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.

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 units systems differ, the fields exchanged between the two programs must go through a transformation of units. There are two possible scenarios of who performs the unit translation. Refer to the appropriate third-party program documentation for further modeling details on units system translation.

Units Translation Performed by SIMULIA Co-Simulation Engine

The units system translation can be done by the SIMULIA Co-Simulation Engine. In this case all solvers must support units translation through the SIMULIA Co-Simulation Engine, and you must declare the units system in the Abaqus model (Units). Units translation can be performed only for field types that have a predefined dimensionality (for example, the velocity field has a predefined dimensionality of LT^{-1}). Field variables in Abaqus do not have a predefined dimensionality; therefore, unit translation is not performed for field variables.

Units Translation Performed by client

In some cases unit translation is done by the third-party solver. In this case you do not need to declare the units system in the Abaqus model.

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.
Abaqus/Explicit cannot use thread-based execution with co-simulation.

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.