System-Level Modeling between Logical and Physical Interactions

This section discusses applications, analysis setup, and execution details for system-level modeling between logical-to-physical co-simulation using the SIMULIA Co-Simulation Services. The logical model is a Functional Mockup Unit (FMU) conforming to the Functional Mockup Interface (FMI) defined by the Modelisar organization.

For more information on the FMI standard or for a list of tools that provide the FMU file export capability, refer to http://fmi-standard.org/. Although you can use FMUs with nonstructural applications, this section focuses on coupling logical models with the Abaqus structural solvers.

This page discusses:

See Also
About Co-Simulation
Preparing an Abaqus Analysis for Co-Simulation
In Other Guides
SIMULIA Co-Simulation Engine FMU Execution
*CO-SIMULATION
*AMPLITUDE
*OUTPUT

ProductsAbaqus/StandardAbaqus/Explicit

Applications

System-level modeling refers to the modeling of systems that can include both physical (structural, thermal, acoustics, computational fluid dynamics, etc.) and logical components. Logical modeling refers to a large class of modeling abstractions often encountered in the engineering practice. Generally speaking, you can designate a part of a system as using a logical modeling abstraction when most (if not all) of the geometry of the part is removed. Physical modeling is the complementary modeling abstraction to logical modeling. Abaqus uses a physical modeling abstraction most of the time; as elements deform, they know precisely about their geometry, thus trying to mimic the real world at a fine-grain level. In many engineering systems the interaction between logical and physical components is paramount, and you cannot fully analyze one without the other.

System-level modeling can be used to couple:

  • Dymola with Abaqus,
  • FMUs conforming to the FMI 2.0 standard with Abaqus,
  • multiple FMUs with one another, and
  • FMUs with models created using the Physics Simulation apps on the 3DEXPERIENCE platform (including structural and computational fluid dynamic models). The models must support the SIMULIA Co-Simulation Services and signal support.

This functionality is not intended for applications where a strong interaction between subsystems exists. 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 as an FMU will likely lead to unstable results.

Preparing an Abaqus Model for a Logical-to-Physical Co-Simulation

To prepare an Abaqus model for a logical-to-physical co-simulation, you need to:

  • identify the Abaqus analysis step,

  • define sensors, and

  • define actuators.

The following sections describe these steps. For more detailed information on co-simulation analysis model creation, see Preparing an Abaqus Analysis for Co-Simulation.

Identifying the Abaqus Analysis Step

The period of time of co-simulation interaction is defined as a co-simulation event. The co-simulation event begins at the start of an Abaqus analysis step and ends by the end of that step; the analysis step is referred to as the co-simulation step. See Identifying an Abaqus Step for Co-Simulation Analysis for the analysis procedures that support co-simulation. An analysis job can contain only one co-simulation step. You can use the restart capability to define additional co-simulation steps.

You can define a co-simulation step where Abaqus exchanges signals with one or more FMUs.

Input File Usage

Use the following option within a step definition:

CO-SIMULATION, PROGRAM=MULTIPHYSICS

Defining Sensors

A sensor is a scalar quantity that can be exported by Abaqus. A sensor can be any nodal or connector element history output variable defined as a named sensor (see Defining Sensors). In addition, some of the whole surface contact and contact pair output history variables can be defined as a named sensor.

Defining Actuators

An actuator is a scalar quantity imported into Abaqus. It acts as an amplitude and can actuate any Abaqus feature that can reference an amplitude, such as concentrated loads, boundary conditions, connector motion/load, distributed pressure, and material properties via field variables.

Input File Usage

Use the following option to define an actuator in Abaqus:

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 is imported from the FMU. 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). Typically, the magnitude of the load or boundary condition should be set to 1.0 so the total magnitude of the signal is applied. This is especially important when the coupling is bidirectional, such as a closed-looped control system.

For example, use the following options to define a force actuator in the 3-direction:

AMPLITUDE, NAME=name, DEFINITION=ACTUATOR
CLOAD, AMPLITUDE=name
101, 3, 1.0

Mapping Signal Names between Abaqus and FMUs

The mapping between actuators and sensors in the Abaqus analysis and the signals in the FMUs is defined in the Co-Simulation Services configuration file. The configuration file defines the simulation properties of the system and the numerical methods employed to simulate the system. It is recommended that you modify an existing configuration file from an example problem to adapt it to your system.