System Archictecture

System Architecture

We seek to design a software integration infrastructure that generalizes the features common to these types of architectures and encapsulates them into a separate toolkit for use by the development community in software integration endeavors. Further, we want to identify a minimal set of domain-independent multiphysics capabilities and factor them onto the infrastructure as "services," such that the services, together with the software integration toolkit, form a general infrastructure for multiphysics capability development. A high-level depiction of the general infrastructure layers is shown in Figure 1. The bottom layer represents a software integration toolkit that provides the basic constructs allowing applications to publish native data structures and functions. In this context, by publish we mean that the application can describe and provide access to native data structures and functions from outside software. Each layer has direct access to the host operating system and is discussed in more detail below.

Figure 1. - Depiction of the abstract layers for the multiphysics infrastructure.

Software Integration Toolkit

At the core of the infrastructure for multiphysics simulation lies an abstraction layer for general software integration in the HPC environment. This layer, which we call the Software Integration Toolkit (SIT), defines the primitive software integration constructs that facilitate the sharing of application-native data and methods across the component-component boundary. All component-component interactions are mediated through the SIT. We identify the following constructs and capabilities as those under purview of the SIT:

• Encapsulates applications into component objects called modules
• Provides constructs for publishing methods and associated metadata
• Provides constructs for publishing data and associated metadata
• Provides associated control mechanisms for inter-language access to published methods and data
• Provides inter-component communication (ICC)

Adapters

Adapters are non-application services that mutate parts of the SIT toward a particular domain or application. Some examples of adapters are as follows:

• Discrete geometry-specific data structures (i.e., mesh-aware data structures)
• Parallel module management (i.e., parallel module loading/unloading and function invocation)
• Parallel data management (i.e., support for inter(intra)-module domain decomposition-aware data structures)

Services

Services are specific capabilities that are provided through the constructs of the SIT that support domain-specific integrated software systems. Services are applications which provide a service. These are very similar to user applications; the general distinction is that service applications typically operate on data owned by other components and provide some sort of functionality for those other components. Service modules use the SIT and adapters to provide such functionalities. Example of services are as follows:

• Parallel I/O for general data, geometry, mesh, and mesh-bound solution data
• Parallel mesh-to-mesh data transfer (e.g., interpolation)
• Simple vector algebra on mesh-bound solution data
• Parallel discrete surface operation (e.g., calculate face normals)
• Parallel surface propagation
• Collective operations for decomposed domains (e.g., reduce on shared nodes)

User Applications

User applications, shown in blue in Figure 1, are those that provide the "primary" domain-specific capabilities that must be integrated into the composite software system. User applications are integrated through the SIT by adapting the application source code or wrapping the application executable or interface using an API provided by the SIT implementation. This API provides the constructs and mechanisms necessary for the application to share its data and functions with the integrated software system. Applications that interact with the coupled system only through the infrastructure are considered fully integrated. All others are considered as only partial integrations. Once integrated, whether fully or partially, the user application becomes a component of the integrated system. Examples of user applications are CFD, CSM, EM, and CTM solvers.

Orchestration

The orchestration layer of the model integration infrastructure is the piece that implements the integrated composite software system. The orchestration layer, as shown in Figure 1, is the most domain-specific piece of the integrated capability. The orchestration layer constructs have access to one or more applications through the SIT and use intrinsic functionalities, or those provided by services, to actuate the interactions between system components. In multiphysics systems, orchestrators typically manage the control flow and implement the coupled timestepping schemes. For example, Rocstar's orchestrator manages control flow, implements the coupled timestepping, and actuates the data transfers between physical domain-specific components, including implementation of the jump conditions.

---

Navigation Links

Technical
Integrated Application Architecture