Structural-to-logical co-simulation

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.

CO-SIMULATION, NAME=co-simulation name, PROGRAM=MULTIPHYSICS, 
CONTROLS=name
CO-SIMULATION CONTROLS, NAME=name

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 for more details.

OUTPUT, HISTORY, FREQUENCY, SENSOR, NAME=sensor_name
NODE OUTPUT, NSET=NSET_Name
nodal output variable

AMPLITUDE, NAME=name, DEFINITION=ACTUATOR

CLOAD, AMPLITUDE=name
101, 3, 1.0

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.

CO-SIMULATION REGION, TYPE=DISCRETE, IMPORT
Actuator_name1, Actuator_name2, etc.
CO-SIMULATION REGION, TYPE=DISCRETE, EXPORT
Sensor_name1, Sensor_name2, etc.

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.

CO-SIMULATION CONTROLS, STEP SIZE=coupling_step_size

CO-SIMULATION CONTROLS (omit the STEP SIZE parameter)

CO-SIMULATION CONTROLS, TIME INCREMENTATION=LOCKSTEP

CO-SIMULATION CONTROLS, 
TIME INCREMENTATION=SUBCYCLE

CO-SIMULATION CONTROLS, TIME MARKS=YES (default)

CO-SIMULATION CONTROLS, TIME MARKS=NO

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.

In the Simulation panel, select SimulationSetup 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.

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 DymolaSolverType

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

In most cases, specifying the following information in the map (.sgn) file is sufficient:

 Analysis: analysisTime analysisTime 1 8

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

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=portNumber

When 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

Alternatively, the following two commands can be used to have Dymola initiate the communication process:

abaqus job=job_name host=machineName port=portNumber

abaqus dymola input=mapFileName port=portNumber