17.4.1 Structural-to-logical co-simulation
Products: Abaqus/Standard Abaqus/Explicit
References
Overview
This section discusses analysis setup, execution, and limitation details for structural-to-logical co-simulation using Abaqus and Dymola. To use co-simulation as described in this section, you will need Dymola version 7.2 or later, with the .DLL option. For more information, see “User's and Installation Guides for Logical-Physical modeling using Abaqus and Dymola” in the Dassault Systèmes Knowledge Base at www.3ds.com/support/knowledge-base.
Preparing an Abaqus model for a structural-to-logical co-simulation
To prepare an Abaqus model for a structural-to-logical co-simulation, you need to:
identify the Abaqus analysis step involved,
identify the interface sensors and actuators to be exchanged, and
define the rendezvousing scheme.
Identifying the Abaqus analysis step
The period of time of co-simulation interaction is defined as a co-simulation event. This event begins at the start of an Abaqus analysis step (the co-simulation step) and ends by the end of that step. Any procedure type in the analysis that supports the co-simulation technique can be a co-simulation step; however, only one co-simulation step per analysis job is allowed. For multiple co-simulation steps, you can use the restart capability to define new co-simulation steps in subsequent analysis jobs.
You can define a co-simulation step in which Abaqus exchanges fields with Dymola at run time. You specify co-simulation controls that define the rendezvousing scheme.
| Input File Usage: | Use the following options within a step definition: |
*CO-SIMULATION, NAME=co-simulation name, PROGRAM=MULTIPHYSICS, CONTROLS=name *CO-SIMULATION CONTROLS, NAME=name |
Defining sensors and actuators
You must define sensors and actuators. Any nodal or connector element history output variable can be defined as a named sensor. In addition, some of the whole surface contact and contact pair output history variables can be defined as a named sensor. See “Sensor definition in Abaqus/Standard and Abaqus/Explicit” in “Output to the output database,” Section 4.1.3, for more details.
| Input File Usage: | Use the following options to define a sensor: |
*OUTPUT, HISTORY, FREQUENCY, SENSOR, NAME=sensor_name *NODE OUTPUT, NSET=NSET_Name nodal output variable Use the following option to define an actuator: *AMPLITUDE, NAME=name, DEFINITION=ACTUATOR There are no data lines associated with this amplitude definition to define the amplitude value at a given simulation time. Instead, the amplitude value at a given simulation time will be imported from the Dymola output. The user-specified name can be referenced in any of the Abaqus options that can refer to an amplitude (such as *CLOAD, *BOUNDARY, *FIELD, and *CHANGE FRICTION). For example, *CLOAD, AMPLITUDE=name 101, 3, 1.0 |
Identifying the sensors and actuators to be exchanged
You must specify the fields that are imported and/or exported in the Abaqus analysis during the co-simulation.
The import definition ensures that the values of the Dymola outputs as computed at the time of the last data exchange are the Abaqus inputs (actuators) and are given as the current values of the specified amplitude names. Equally important, the export definition ensures that the current values of the Abaqus outputs (sensors) are given as the values of the Dymola inputs at the time of the data exchange.
You can specify up to 5000 actuators/sensors.
| Input File Usage: | Use the following options to identify the sensors and actuators to be exchanged: |
*CO-SIMULATION REGION, TYPE=DISCRETE, IMPORT Actuator_name1, Actuator_name2, etc. *CO-SIMULATION REGION, TYPE=DISCRETE, EXPORT Sensor_name1, Sensor_name2, etc. The user-defined names on the data lines are comma-separated with eight entries per line. Each name must be less than 80 characters long. Use more than one data line if necessary. |
Defining the rendezvousing scheme: target time
The coupling step is the period between two consecutive exchanges and, consequently, defines the exchange frequency between Abaqus and Dymola. 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). In most cases, exchanging data every Abaqus increment is sufficient.
Determining the target time
During a coupled simulation between Abaqus and Dymola, the current coupling step size is negotiated by both solvers to establish a suitable coupling step size. Each solver “suggests” a coupling step size. The smaller of these suggested step sizes is then selected. Abaqus can suggest either a constant or a variable coupling step size. For a variable coupling step size, Abaqus sets the suggested coupling step size equal to the next suggested increment size computed by the automatic time incrementation scheme. Using a variable coupling step size typically leads to the most accurate solution.
Abaqus and Dymola exchange the coupling step size and establish a “negotiated” coupling step size based on the smaller of the solvers’ suggested values. This coupling step size is then used to advance the target time for the next coupling rendezvous.
| Input File Usage: | Use the following option to have Abaqus suggest a constant coupling step size: |
*CO-SIMULATION CONTROLS, STEP SIZE=coupling_step_size Use the following option to have Abaqus suggest a variable coupling step size: *CO-SIMULATION CONTROLS (omit the STEP SIZE parameter) |
How Abaqus meets the target time
In addition to defining the coupling step size, you define co-simulation controls to describe how Abaqus advances to its next target time. By default, Abaqus may perform several time increments during the coupling step period, referred to as “subcycling.” Subcycling allows Abaqus to cut back the current increment size and take smaller increments to resolve nonlinear events.
Alternatively, you can force Abaqus to use an increment size that is equal to the negotiated coupling step size, referred to as “lockstep.” When proceeding in a lockstep manner, Abaqus will not be able to reduce the time increment to resolve nonlinear events. Consequently, Abaqus terminates the simulation in cases where the nonlinear events require that the increment size be reduced.
| Input File Usage: | Use the following option to have Abaqus suggest a constant coupling step size: |
*CO-SIMULATION CONTROLS, TIME INCREMENTATION=LOCKSTEP Use the following option to have Abaqus suggest a variable coupling step size: *CO-SIMULATION CONTROLS, TIME INCREMENTATION=SUBCYCLE |
Reaching target times
You can control how accurately Abaqus meets the target time. The Abaqus target times can be reached in an “exact” or “loose” manner. By default, Abaqus reaches the target times in an exact manner; that is, Abaqus adjusts the time increment as necessary to exactly meet the target time. Alternatively, you can direct Abaqus to meet the target times in an approximate or loose manner, performing a co-simulation exchange only after a target time is passed, with time incrementation in Abaqus advancing without regard for the target time. In certain cases, such as when Abaqus takes many more increments than Dymola, the loose approach may be more cost effective.
| Input File Usage: | Use the following option to reach target times in an exact manner: |
*CO-SIMULATION CONTROLS, TIME MARKS=YES (default) Use the following option to reach target times in a loose manner: *CO-SIMULATION CONTROLS, TIME MARKS=NO |
Preparing the Dymola model for the coupled simulation
To prepare your Dymola model for coupled simulation, you need to:
define named inputs and outputs,
translate the model with the .DLL option to produce dymosim.dll,
define co-simulation parameters, and
map the signal (sensors and actuators) names in Abaqus to signal names in Dymola.
The following sections briefly describe these steps; they are not intended to describe how to use Dymola. For further information on Dymola and its user interface, refer to the relevant user's manuals. After these steps are complete, you must have the following files in the directory from which the Dymola analysis will be run:
libdsdll.dll corresponding to the Dymola installation,
dymosim.dll corresponding to the desired Dymola model, and
a map (.sgn) file whose contents are described below.
Defining named inputs and outputs
The Dymola graphical editor provides the most convenient way to define inputs and outputs. From the Modelica library palette, drag Modelica.Blocks.Interfaces.RealInput blocks onto the canvas to define inputs (blue-filled triangles). Use Modelica.Blocks.Interfaces.RealOutput blocks to define outputs (hollow triangles). You can change the names assigned by default via popup dialog boxes. It is important that you use all uppercase letters when specifying the names of the input and output blocks.
Translating the model with the .DLL option
In the Simulation panel, select Simulation
Setup and then click the Compiler tab. Toggle on Export model as DLL with API, and click OK. In the Simulation panel, select SimulationTranslate. A file named dymosim.dll is created in the current working folder. You should pay particular attention to the warning/error messages issued during translation. A successful co-simulation analysis can be conducted only if the translation was successful. The dymosim.dll file includes information related to this specific model. If co-simulation with other Dymola models is necessary, make sure to change the current working directory so that the dymosim.dll file is not overwritten.
Defining co-simulation parameters
While the dymosim.dll file includes information about the Dymola model itself, it does not include information about the duration of the analysis, the frequency of data exchanges, the required output frequency, and the solver type to be used for the time integration in Dymola. You need to provide this information in a separate text file, mapFileName.sgn, using the following format:
Analysis: analysisTime couplingStepSize OutputPointsPerCouplingStep DymolaSolverTypeGuidelines for providing the information are as follows:
Analysis must be followed immediately by a colon (no spaces). A single blank space follows the colon after which the four quantities are given separated by single blank spaces.
analysisTime must match the analysis time specified in the Abaqus co-simulation step.
couplingStepSize must match the coupling step size specified in the Abaqus model, if it was specified. The most convenient way to set up the co-simulation controls is to use the default subcycling method and to have Abaqus suggest a variable coupling step size. Then you can specify couplingStepSize as being equal to analysisTime to allow the co-simulation to exchange data every Abaqus increment.
OutputPointsPerCouplingStep sets the frequency of output generation in Dymola. A value of 1 is normally sufficient.
Refer to the Dymola User’s Manual when choosing a solver type. Typically, solverType 8 performs the best, although it is slightly more expensive than other solvers. The CPU cost of the co-simulation analysis is typically dominated by the Abaqus analysis and, hence, the performance of the Dymola solver is of little consequence to the performance of the co-simulation analysis.
Analysis: analysisTime analysisTime 1 8
Mapping signal names
It is quite likely that in common practice the Dymola and the Abaqus models are prepared by different engineers in the organization as the finite element analyst may not have any controls expertise and vice versa. It is reasonable to assume that the names used for inputs in Dymola would not match the names used for Abaqus sensors and/or the names for outputs in Dymola would not match the names for Abaqus actuators. In such cases, you can modify the names used in one of the analysis programs. If that is not possible, the map (.sgn) file can be used to map signal names to be exchanged from Abaqus to Dymola. You can add the following optional lines immediately after the Analysis line described above:
Actuators: AbaqusActuatorName1 DymolaOutputName1 AbaqusActuatorName2 DymolaOutputName2 Etc. Sensors: AbaqusSensorsName1 DymolaInputName1 AbaqusSensorsName1 DymolaInputName1 Etc.Guidelines for providing the information are as follows:
Actuators is followed by a list of name pairs to match Abaqus actuators to Dymola outputs. Use as many lines as needed (up to 5000).
Similarly, Sensors is followed by a list of name pairs to match Abaqus sensors to Dymola inputs. Use as many lines as needed (up to 5000).
Executing the coupled analysis
You execute the Abaqus job as described in “Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” Section 3.2.2. You execute the Dymola job as described in “Dymola model execution,” Section 3.2.5. Abaqus and Dymola can be run on heterogeneous and remote platforms that are located on the same network domain. For co-simulation purposes, Dymola has to be run on a Windows 32-bit or 64-bit system while Abaqus can be run on any supported platform available. The communication between Abaqus and Dymola is via Transmission Control Protocol (TCP) sockets. To start a coupled simulation between Abaqus and Dymola, one of the solvers must initiate the communication process, while the other solver must connect to the initiated communication process. Either Abaqus or Dymola can initiate the communication process; however, the starting method differs for each solver. Each method is discussed in the following sections.
You will need to know the network host ID for the machine on which the communication process was started. This ID can either be a host name or an Internet Protocol (IP) address. The port designation allows different applications to maintain their own channels of communication. Set the port number to any available port on your system. Port numbers in the range of 0 to 65535 can be assigned. In general, port numbers under 1024 are reserved by the operating system and should be avoided. You can run multiple analysis jobs simultaneously on a given system by assigning each analysis a unique port number.
The Abaqus and Dymola-related input files do not have to be located in the same directory. If the two co-simulation analyses are run on different platforms that are not binary compatible (such as a Linux 64-bit system for the Abaqus job and a 32-bit Windows system for the Dymola job), then ASCII data exchange must be enabled. To accomplish that, add the following two lines in your local environment file for machines used for the co-simulation analysis:
import os os.environ['ABAQUS_DCI_FORMAT']='ASCII'See “Using the Abaqus environment files,” Section 4.1 of the Abaqus Installation and Licensing Guide, for details about the environment files.
Abaqus initiates the communication process
To have Abaqus initiate the communication process, you supply only the port number (and not the host name) on the command line; for example, the Abaqus job can be run using the following command:
abaqus job=job_name port=portNumberWhen Abaqus initiates the communication process, Dymola must connect to the host and the specified port where the Abaqus analysis was started. The following command can be used for the Dymola job:
abaqus dymola input=mapFileName host=machineName port=portNumber
Limitations
Structural-to-logical co-simulation using Abaqus and Dymola is not intended for applications in which the mechanical/thermal system itself is split between the two analysis programs. For example, results obtained for a coupled analysis in which the tires and the road are modeled in Abaqus while the suspension and the body are modeled in Dymola will likely lead to unreliable results.