As an illustrative example of such a complex simulation application, we are developing an integrated multi-physics rocket simulation code from several stand-alone pieces, at the Center for Simulation of Advanced Rockets (University of Illinois). The individual codes include a computational fluid dynamics (CFD) code (Rocflo), and a structural analysis code (Rocsolid). These codes are coupled together with an interface code (Rocface). Together, these codes simulate solid propellant rockets. Rocflo solves the core flow equations in the inner part of the rocket. Rocsolid models the deformation of the solid propellant, liner, and casing. Rocface takes care of data transfer and interpolation of temperature, pressure, and displacement between these two components.
Several researchers have been working on different physics of the rocket as part of the center, and several additional codes to model these physics, such as combustion (Rocburn), crack propagation (Rocfrac), and behavior of aluminum particles ejected into the core (Rocpart) have been developed. These codes have to be integrated to perform a complete multi-physics simulation of the rocket. While some of these new codes have to be integrated more tightly within the individual applications (such as ejection of aluminum particles to Rocflo), some of them (such as crack propagation) need to interface with both Rocflo and Rocsolid. Some of them need efficient coupling with the existing codes, since the interaction among them will be frequent (such as between Rocflo and the combustion code.)
These codes are being developed more or less in isolation (many are based on legacy codes) by different researchers. One of the approaches for integrating them has been to run them as separate applications, while interactions among them are serialized by dumping interface data on the file system or through socket-like mechanisms1.1. But given the nature of the required integration, this approach results in inefficient coupling for large systems. While we want the individual software components to be modular and independently developed, these components may not always have large enough grainsize to ignore the efficiency of coupling. Also, in order to be scalable to a large number of processors, especially while solving a fixed-size problem, it is required that the coupling efficiency be maximized. Therefore, it is imperative that the communicating software components be part of the same process in order to have efficient coupling between software components (known in the component terminology as the ``in-process components'' or ``inproc servers'' [68].) One of the approaches taken earlier for developing the integrated rocket simulation is to have a single orchestration module that invokes these codes as in-process subroutines, while these codes interact with each other using shared data. This approach forces a common programming paradigm on individual codes, while requiring them to have intricate knowledge of each other's data structures and control transfer strategies, thus hampering modularity.
The current approach for integration of rocket simulation codes is based on Roccom [37]. Roccom is a component architecture motivated by the need to integrate different components of the rocket simulation code together into a single application. Roccom client components can exist as independent processes or within the same process. These components register data such as the mesh geometry, connectivity, and values of various physical parameters on the mesh entities with Roccom, which facilitates exchange of these data among components. Roccom has a prespecified set of data types (that are required for physical simulations) that can be exchanged between components. If a new type of data needs to be exchanged, such as in the case of integrating a component code that models the physical domain as an oct-tree, one has to extend Roccom to support it. We believe in the need of a general purpose component architecture, which does not limit the domain of parallel applications to physical simulations. In addition, one can easily implement domain-specific component architectures such as Roccom on top of such general purpose architectures.
This thesis describes our work in building a general-purpose component architecture, Charisma, for parallel applications with in-process components. Goals of such a component architecture are:
In this thesis, we present work on each of these aspects of Charisma.