17.3.1 Structural-to-structural co-simulation
Products: Abaqus/Standard Abaqus/Explicit Abaqus/CAE
Overview
Co-simulation between two structural solvers (solvers exchanging displacements and/or rotations and the conjugate fields' force and/or moments) represents a very strong physics coupling and requires special treatment at the co-simulation interface. Abaqus supports co-simulation between Abaqus/Standard and Abaqus/Explicit by providing specialized interface handling. Although you can perform a structure-to-structure co-simulation between two Abaqus/Standard analyses or between two Abaqus/Explicit analyses, it is not recommended due to the lack of proper handling at the interface.
This section discusses analysis setup, execution, and limitation details specific to Abaqus/Standard to Abaqus/Explicit co-simulation.
Refer to “Dynamic impact of a scooter with a bump,” Section 2.4.1 of the Abaqus Example Problems Guide, for an example of Abaqus/Standard to Abaqus/Explicit co-simulation.
Identifying the Abaqus step for the co-simulation analysis
The following Abaqus/Standard analysis procedures can be used for an Abaqus/Standard to Abaqus/Explicit co-simulation:
The following Abaqus/Explicit analysis procedure can be used for an Abaqus/Standard to Abaqus/Explicit co-simulation:| Input File Usage: | Use the following option within a step definition for an Abaqus/Standard to Abaqus/Explicit co-simulation: |
*CO-SIMULATION, PROGRAM=ABAQUS |
| Abaqus/CAE Usage: | Use the following option for an Abaqus/Standard to Abaqus/Explicit co-simulation: |
Interaction module: Create Interaction: Standard-Explicit co-simulation |
Identifying the co-simulation interface region
Interaction between the Abaqus/Standard and Abaqus/Explicit models takes place through a common interface region.
You can specify an interface region using either node sets or surfaces when coupling Abaqus/Standard to Abaqus/Explicit. You must, however, be consistent in your region definition in Abaqus/Standard and Abaqus/Explicit; if you define a co-simulation region with a node set or node-based surface in one analysis, you must use the same type of co-simulation region definition in the other analysis. For node-based surfaces the nodes have to be co-incident since no topology information is provided to conservatively map fields between the Abaqus/Standard and Abaqus/Explicit models. Likewise, if you define a co-simulation region with an element-based surface in one analysis, you must define your co-simulation region with an element-based surface in the other analysis.
You may have dissimilar meshes in regions shared in the Abaqus/Standard and Abaqus/Explicit model definitions. In some cases, however, you can improve solution stability and accuracy by ensuring that you have matching nodes at the interface (see “Dissimilar mesh-related limitations). In these cases you can use the modeling practice described in “Ensuring matching nodes at the interface regions,” Section 26.4 of the Abaqus/CAE User's Guide, to ensure these matching nodes.
| Input File Usage: | Use the following option to define an element-based or node-based surface as a co-simulation region in an Abaqus model: |
*CO-SIMULATION REGION, TYPE=SURFACE (default) surface_A 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 Only one *CO-SIMULATION REGION option can be defined in each Abaqus analysis. In addition, only one node set or surface can be defined. |
| Abaqus/CAE Usage: | Interaction module: Create Interaction: Standard-Explicit co-simulation: Surface or Node Region: select region |
Identifying the fields exchanged across a co-simulation interface
For Abaqus/Standard to Abaqus/Explicit co-simulation, you do not define the fields exchanged; they are determined automatically according to the procedures and co-simulation parameters used.
Defining the rendezvousing scheme
For structural-to-structural co-simulation, you must specify co-simulation controls for each analysis and create a configuration file; the consistency of the parameters is confirmed during execution. The SIMULIA Co-Simulation Engine configuration file is used to define the time incrementation process and the frequency of exchange between the two Abaqus analyses. Abaqus/CAE automatically creates and uses this configuration file. If you are not using Abaqus/CAE to perform the co-simulation, you must create the configuration file manually.
Predefined templates are available for the following co-simulation schemes:
You can force Abaqus/Standard to use the same increment size as Abaqus/Explicit, or
you can allow the increment sizes in Abaqus/Standard to differ from those in Abaqus/Explicit (subcycling).
| Input File Usage: | Use both of the following options to specify co-simulation controls: |
*CO-SIMULATION, PROGRAM=ABAQUS, CONTROLS=name *CO-SIMULATION CONTROLS, NAME=name |
| Abaqus/CAE Usage: | Interaction module: Create Interaction: Standard-Explicit co-simulation |
Time incrementation scheme
You can force Abaqus/Standard to use the same increment size as Abaqus/Explicit, or you can allow the increment sizes in Abaqus/Standard to differ from those in Abaqus/Explicit (subcycling). The time incrementation scheme that you choose for coupling affects the solution computational cost and accuracy but not the solution stability.
The subcycling scheme is frequently the most cost effective since Abaqus/Standard time increments, free of any forced co-simulation time incrementation constraints, are commonly much longer than Abaqus/Explicit time increments. The subcycling scheme, however, may be less cost effective when a large portion of the nodes in the model are at the co-simulation interface. This is because Abaqus/Standard performs a set of stabilization operations at the interface (a “free solve”) for each increment in the Abaqus/Explicit analysis. These free-solve operations require an implicit solution of a dense system of equations that scale with the number of interface nodes. In cases of a large number of interface nodes the computational cost of this interface solve can exceed any cost savings seen due to subcycling. Hence, for a model where a significant share of the nodes are at the co-simulation interface performance may be poorer with the subcycling scheme.
Forcing Abaqus/Standard to use the same increment size as Abaqus/Explicit
You can force Abaqus/Standard to match the increment size of Abaqus/Explicit, and fields will be exchanged at each of the shared increments.
| Input File Usage: | Use the following option in the Abaqus/Standard analysis and in the Abaqus/Explicit analysis: |
*CO-SIMULATION CONTROLS, TIME INCREMENTATION=LOCKSTEP |
| Abaqus/CAE Usage: | Use the following input in the Abaqus/Standard analysis and in the Abaqus/Explicit analysis: |
Interaction module: Create Interaction: Standard-Explicit co-simulation: Incrementation control: Lock time steps |
Allowing the increment sizes in Abaqus/Standard to differ from those in Abaqus/Explicit
You can allow the Abaqus/Standard increment size to differ from those in Abaqus/Explicit (subcycling). In this case fields will be exchanged as needed.
| Input File Usage: | Use the following option in the Abaqus/Standard analysis and in the Abaqus/Explicit analysis: |
*CO-SIMULATION CONTROLS, TIME INCREMENTATION=SUBCYCLE |
| Abaqus/CAE Usage: | Use the following input in the Abaqus/Standard analysis and in the Abaqus/Explicit analysis: |
Interaction module: Create Interaction: Standard-Explicit co-simulation: Incrementation control: Allow subcycling |
Controlling interface matrix factorization frequency
For the subcycling time incrementation scheme an interface solve is performed, by default, in Abaqus/Standard for every Abaqus/Explicit increment. This solve can be significantly costly for two reasons. First, the interface matrix used for the interface solve is dense and its size scales with the number of interface nodes. Second, the interface matrix changes every Abaqus/Explicit increment, requiring factorization in Abaqus/Standard for every Abaqus/Explicit increment. You can reduce the impact of this cost by approximating the interface matrix and factorizing it typically once for the duration of an Abaqus/Standard increment, rather than for each Abaqus/Explicit increment. However, if the Abaqus/Explicit stable time increment changes significantly, the interface matrix is refactored for stability reasons.
Allowing Abaqus/Standard to factorize the interface matrix every Abaqus/Explicit increment
Factorizing the interface matrix every Abaqus/Explicit increment is the default approach.
| Input File Usage: | Use the following option in the Abaqus/Standard analysis: |
*CO-SIMULATION CONTROLS, FACTORIZATION FREQUENCY=EXPLICIT INCREMENT |
| Abaqus/CAE Usage: | Factorizing the interface matrix every Abaqus/Explicit increment is used by default in Abaqus/CAE. |
Forcing Abaqus/Standard to factorize the interface matrix once per Abaqus/Standard increment
When the number of interface nodes is large, the cost of the interface factorization can be significantly reduced by using this approach. Only the interface matrix factorization is performed once per Abaqus/Standard increment; the interface solve is performed every Abaqus/Explicit increment using this factorized interface matrix. Since this approach approximates the interface matrix, it may slightly increase the drift in the displacement solution at the co-simulation interface. The performance gain with this method depends on the number of interface nodes, the subcycling ratio (which is the ratio between Abaqus/Standard and Abaqus/Explicit increments), and the size of the models. For models with greater than 100 interface nodes and a subcycling ratio greater than 50, this method typically reduces the analysis time by a factor between 1.2 and 3.0. The performance gain increases for larger subcycling ratios and decreases for larger models.
| Input File Usage: | Use the following option in the Abaqus/Standard analysis: |
*CO-SIMULATION CONTROLS, FACTORIZATION FREQUENCY=STANDARD INCREMENT |
| Abaqus/CAE Usage: | Factorizing the interface matrix once per Abaqus/Standard increment is not supported in Abaqus/CAE. |
Coupling step size
The coupling step size is the period between two consecutive co-simulation data exchanges between Abaqus/Standard and Abaqus/Explicit and always equals the current Abaqus/Explicit increment size.
When using the subcycling method, this data exchange does not represent a constraint on Abaqus/Standard incrementation; the Abaqus/Standard analysis advances in time using its normal time incrementation logic.
Creating a configuration file
You can use predefined templates to create a configuration file for the coupling schemes described above. Table 17.3.1–1 describes the two predefined templates available for Abaqus/Standard to Abaqus/Explicit co-simulation and lists example configuration files that you can review.
Table 17.3.1–1 Templates for structural-to-structural co-simulation.
| Structural-to-structural co-simulation: subcycling | Coupling scheme: Allow Abaqus/Explicit to subcycle |
| template_std_xpl_subcycle | |
| Example file: exa_std_xpl_subcycle.xml | |
| Structural-to-structural co-simulation: lockstep | Coupling scheme: Abaqus/Standard and Abaqus/Explicit use a single increment per coupling step (lockstep) |
| template_std_xpl_lockstep | |
| Example file: exa_std_xpl_lockstep.xml |
To obtain an example configuration file, you can use the abaqus fetch utility. For example, to obtain the example for Abaqus/Standard to Abaqus/Explicit subcycling, use the following command:
abaqus fetch job=exa_std_xpl_lockstepThe example file exa_std_xpl_lockstep.xml is shown below.
<?xml version="1.0" encoding="utf-8"?>
<CoupledMultiphysicsSimulation>
<template_std_xpl_subcycle>
<Standard_Job>standard_job_name</Standard_Job>
<Explicit_Job>explicit_job_name</Explicit_Job>
<duration>duration_value</duration>
</template_std_xpl_subcycle>
</CoupledMultiphysicsSimulation>In certain cases you may need to use co-simulation configuration features that are not described in the predefined templates. For example, you may wish to change the dissimilar mesh mapping search tolerances; these tolerances are available generally in the configuration file but are not described in the predefined templates. For these cases, you must create an elaborated configuration file; for more information, see “Using elaborated configuration files” in “Preparing an Abaqus analysis for co-simulation,” Section 17.2.1.
Executing the coupled analysis
You execute the co-simulation interactively in Abaqus/CAE or from the command line, as described in “Executing a co-simulation,” Section 17.3.4.
Diagnostics information
The Abaqus/Standard job provides detailed descriptions of co-simulation operations in the message (.msg) file. For the subcycling scheme the status (.sta) file provides summary information indicating when the interface calculations followed by re-solve of the increment are made, as shown in the following example status file. The E suffix in the attempt-count entry (column 3) indicates an increment performing interface calculations. An increment without the E suffix indicates re-solve of the increment.
SUMMARY OF JOB INFORMATION:
STEP INC ATT SEVERE EQUIL TOTAL TOTAL STEP INC OF DOF IF
DISCON ITERS ITERS TIME/ TIME/LPF TIME/LPF MONITOR RIKS
ITERS FREQ
1 1 1E 0 1 1 0.000 0.000 0.001000
1 1 1 0 3 3 0.00100 0.00100 0.001000
1 2 1E 0 1 1 0.00100 0.00100 0.001000
1 2 1 0 3 3 0.00200 0.00200 0.001000
1 3 1E 0 1 1 0.00200 0.00200 0.001000
1 3 1 0 2 2 0.00300 0.00300 0.001000
1 4 1E 0 1 1 0.00300 0.00300 0.001000
1 4 1 0 3 3 0.00400 0.00400 0.001000The Abaqus/Explicit job provides summary descriptions of co-simulation operations in the status (.sta) file.
Limitations
The following limitations apply to Abaqus/Standard to Abaqus/Explicit co-simulation in addition to the limitations discussed in “Preparing an Abaqus analysis for co-simulation,” Section 17.2.1.
General limitations
Displacement compatibility at the co-simulation interface is not maintained when you allow the Abaqus/Standard increment size to differ from that in Abaqus/Explicit (i.e., when you specify subcycling as a co-simulation time incrementation control). In this case velocity compatibility is maintained, but you may see small amounts of displacement mismatch between Abaqus/Standard and Abaqus/Explicit as the simulation advances in time. This “drift” is more pronounced if severe nonlinearity such as plastic deformation occurs at the co-simulation interface. You can control this drift by adjusting Abaqus/Standard solution parameters so that the Abaqus/Standard increment size is reduced (e.g., by limiting the maximum time increment size or specifying a smaller half-increment residual tolerance for implicit dynamic analyses).
Nodal transformations are not permitted on the co-simulation region nodes.
The ALE technique may not be used in elements attached to co-simulation region nodes.
Fully coupled temperature-displacement elements can be used, but no temperature quantities are exchanged.
An Abaqus/Standard static stress analysis cannot be used with the lockstep time incrementation scheme in Abaqus/Standard to Abaqus/Explicit co-simulation.
Only points and surface regions are allowed; coupling volume regions is not supported.
Only a single region can be defined as the interface region; multiple interface regions are not supported.
Dissimilar mesh-related limitations
When your Abaqus/Standard and Abaqus/Explicit co-simulation region meshes differ, the following limitations apply:
Solution accuracy may be affected when your co-simulation region meshes are not uniform in the presence or absence of rotational degrees of freedom; for example, if a continuum element mesh is locally reinforced with beam or shell elements at the co-simulation region interface.
In cases where the stress state near the co-simulation interface is significant (approaching 1% or more) relative to the material stiffness, you may observe appreciable irregular mesh distortion if the mesh density adjacent to the co-simulation region differs greatly between the Abaqus/Explicit and Abaqus/Standard models. For example, this effect is common with large deformation of hyperelastic materials. You can minimize this effect by choosing a similar or finer mesh at the Abaqus/Standard co-simulation region when using the subcycling time integration scheme or by choosing a similar or finer mesh at the Abaqus/Explicit co-simulation region when using the lockstep time integration scheme.
Abaqus/Standard analysis limitations
Abaqus/Standard elements that have no equivalent degree-of-freedom counterpart in Abaqus/Explicit cannot be connected to co-simulation region nodes. These elements include
Axisymmetric elements with twist degrees of freedom (the CGAX element family)
Axisymmetric solid elements with asymmetric deformation (the CAXA element family)
Generalized plane strain elements (the CPEG element family)
Coupled pore pressure-displacement elements
Heat transfer and thermal-electrical elements
Acoustic elements
Piezoelectric elements
A co-simulation region node cannot be a slave node in a tie constraint, an MPC constraint, or a kinematic coupling constraint.
Abaqus/Explicit analysis limitations
Stability and accuracy of the co-simulation solution may be adversely affected when the following model features are defined at or near the co-simulation region:
Connector elements connected to co-simulation region nodes.
Co-simulation region nodes that participate in a tie constraint, an MPC constraint, or a kinematic coupling constraint.