Products: Abaqus/Standard Abaqus/Explicit Abaqus/CAE
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 Manual, for an example of Abaqus/Standard to Abaqus/Explicit co-simulation.
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 |
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. 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 Manual, 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 |
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.
Co-simulation controls are used to control the time incrementation process and the frequency of exchange between the two Abaqus analyses.
| 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 |
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.
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 |
You can allow the Abaqus/Standard increment size to differ from those in Abaqus/Explicit. 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 |
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.
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. |
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. |
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, but performs data exchanges as needed at the coupling step size intervals.
If you do not specify a constant coupling step size, Abaqus/Standard and Abaqus/Explicit use the next Abaqus/Explicit increment size as the coupling step size.
| Input File Usage: | Use the following option in either or both of the Abaqus/Standard and Abaqus/Explicit analyses: |
*CO-SIMULATION CONTROLS (omit the STEP SIZE parameter) |
| Abaqus/CAE Usage: | Use the following input in the Abaqus/Standard and Abaqus/Explicit analyses: |
Interaction module: Create Interaction: Standard-Explicit co-simulation: Coupling step period: Determined by analysis |
A constant user-defined coupling step size can be specified. Since data exchange occurs at every Abaqus/Explicit increment, the Abaqus/Explicit increment will be set equal to the user-defined coupling step size. This is functionally equivalent to specifying direct user control on the increment size in Abaqus/Explicit. In Abaqus/Standard the step size parameter is ignored for Abaqus/Standard to Abaqus/Explicit co-simulation.
| Input File Usage: | In the Abaqus/Explicit analysis you may optionally specify a step size: |
*CO-SIMULATION CONTROLS, STEP SIZE=coupling_step_size |
| Abaqus/CAE Usage: | Use the following input in the Abaqus/Explicit analysis: |
Interaction module: Create Interaction: Standard-Explicit co-simulation: Coupling step period: Specified: coupling_step_size |
You execute the Abaqus/Standard and Abaqus/Explicit jobs as described in “Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD co-simulation execution,” Section 3.2.4. By default, the Abaqus/Explicit packager and analysis are both run in double precision to avoid numerical instabilities.
You can execute the coupled analysis interactively in Abaqus/CAE as described in “Understanding co-executions,” Section 19.4 of the Abaqus/CAE User's Manual.
| Input File Usage: | Enter the following input on the command line: |
abaqus cosimulation cosimjob=cosim-job-name job=job-name-A,job-name-B |
| Abaqus/CAE Usage: | Job module: |
The timeout execution parameter specifies the amount of time in seconds that each analysis waits to receive the co-simulation message expected from the other analysis that is running. The default timeout value is 60 minutes when submitting jobs using the command line options and 10 minutes when executing the jobs in Abaqus/CAE. When the timeout period is large compared to typical analysis increment wallclock times, you have greater flexibility in starting jobs and performing operations that precede the co-simulation analysis step. Examples where this flexibility is needed include: job submission using queues, analyses where steps that precede the co-simulation step have long run times, and cases where one job is resubmitted because of an input error. However, a large timeout period can cause problems when one of the co-simulation jobs fails (for reasons such as convergence issues or availability of computer resources) before the initial co-simulation communication is established. In these cases you may prefer to kill the job left running rather than have it wait the entire timeout period.
Use the following command to submit a co-simulation between an Abaqus/Standard analysis called “std” and an Abaqus/Explicit analysis called “xpl”:
abaqus cosimulation cosimjob=beam job=std,xpl
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.
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.
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.
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 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.
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.