Automated Interoperability Tools

In human cultures, membership in a community often implies sharing a common language. This holds as much for computer programming languages as for natural human tongues. Certain languages dominate certain research communities. As a result, the modern drive towards multidisciplinary studies inevitably leads to mixed-language development. As noted in the preface, survey evidence suggests that approximately 85% of high-performance computing users write in some flavor of C/C++/C#, whereas 60% write in Fortran. These data imply that at least 45% write in both Fortran and C/C++/C#, so the union of these two language families likely contains the most important pairings in mixed-language scientific programming.

In many settings, the language version matters as much as the language identity. For example, interfacing other languages with object-oriented Fortran 2003 poses a much broader set of challenges than does interfacing with procedural Fortran 77 or even object-based Fortran 95. It also matters whether one language invokes code in a second language, the second invokes code in the first, or both. As suggested by Rasmussen et al. (2006), one can account for invocation directionality by considering ordered pairs of languages, where the order determines which language is the caller and which is the callee.

Consider a set {A,B,C, …} of N dialects, where each member is a language or language version distinct from each other member.

The Problem

While the abstract calculus and strategy patterns apply to the integration of a single physics abstraction, our chief concern lies in linking multiple abstractions. This poses at least two significant software design problems. The first involves how to facilitate interabstraction communication. The GoF addressed interabstraction communication with the mediator pattern. When N objects interact, a software architect can reduce the N(N−1)+ associations between the objects to 2N associations by employing a mediator.

The mediator association count stems from the requirements that the Mediator know each communicating party and those parties know the Mediator. For example, in a mediator implementation presented by Gamma et al. (1995), the sender passes a reference to itself to the mediator. The sender must be aware of the mediator in order to know where to send the message. Likewise, the mediator must be aware of the sender in order to invoke methods on the sender via the passed reference. Figure 8.1 illustrates the associations in an atmospheric boundary layer model, wherein the air, ground, and cloud ADTs might solve equation sets for the airflow, ground transpiration, and discrete droplet motion, respectively.

A second and conceptually more challenging problem concerns how one assembles quantities of an inherently global nature – that is, information that can only be determined with simultaneous knowledge of the implementation details of each of the single-physics abstractions.

The Problem

The context of abstract calculus is the construction of numerical software that approximates various differential and integral forms. Two pairs of conflicting forces arise in this context. In the first pair, the low-level nature of the mathematical constructs provided by mainstream programming languages constrains the design of most scientific programs. A desire for syntax and semantics that naturally represents the much richer mathematical language of scientists and engineers opposes this constraint.

The C++ language contains native scalar and one-dimensional array variables. The C++ STL extends these in vectors with nice properties such as automatic memory management, including sizing and resizing upon assignment. Fortran 2003 provides similar capabilities with its multidimensional allocatable array construct. It also provides numerous useful intrinsic procedures for determining array properties including size, shape, maximum element, and minimum element, as well as intrinsic procedures and operators for combining arrays into sums, matrix vector products, and other derived information. It is common in scientific and engineering work to build up from these native constructs a set of array classes with a variety of additionally useful methods (Barton and Nackman 1994; Heroux et al. 2005). Nonetheless, the resulting objects model very low-level mathematical entities in the sense that one typically arrives at these entities after fairly involved derivations from, and approximations to, much higher-level constructs.

This appendix summarizes the Unified Modeling Language (UML) diagrammatic notation employed throughout this book along with the associated terminology and brief definitions of each term. We consider the elements that appear in the five types of UML diagrams used in the body of the current text: use case, class, object, package, and sequence diagrams. At the end of the appendix, we give a brief discussion of Object Constraint Language (OCL), a declarative language for describing rules for UML models.

Use Case Diagrams

A use case is a description of a system's behavior as it responds to an outside request or input. It captures at a high level who does what for the system being modeled. Use cases describe behavior, focusing on the roles of each element in the system rather than on how each element does its works.

A use case diagram models relationships between use cases and external requests, thus rendering a visual overview of system functionality. Figure B.1 reexamines the fin heat conductor analyzer diagram from Figure 2.6, adding notations to identify the elements of the use case diagram.

Use case diagrams commonly contain the following elements:

1. Actors: people or external systems that interact with the system being modeled. Actors live outside the system and are the users of the system. Typically actors interact with the system through use cases. In UML, actors are drawn as stick figures. In the fin analyzer system example, system architect, thermal analyst, and numerical analyst are actors.

2. […]

Toward a Scalable Abstract Calculus

The canonical contexts sketched in Section 4.3 and employed throughout Part II were intentionally low-complexity problems. Such problems provided venues for fleshing out complete software solutions from their high-level architectural design through their implementation in source code. As demonstrated by the analyses in Chapter 3, however, the issues addressed by OOA, OOD, and OOP grow more important as a software package's complexity grows. Complexity growth inevitably arises when multiple subdisciplines converge into multiphysics models. The attendant increase in the scientific complexity inevitably taxes the hardware resources of any platform employed. Thus, leading-edge research in multiphysics applications must ultimately address how best to exploit the available computing platform.

Recent trends in processor architecture make it clear that fully exploiting the available hardware on even the most modest of computing platforms necessitates mastering parallelism. Even laptop computers now contain multicore processors, and the highest-end machines contain hundreds of thousands of cores. The process of getting a code to run efficiently on parallel computers is referred to as getting a code to scale, and code designs that facilitate scaling are termed scalable. The fundamental performance question posed by this chapter is whether one can construct a scalable abstract calculus. The Sundance project (Long 2004) has already answered this question in the affirmative for C++.

Essentials

Whereas code reuse played an important role in Part I of this text, design reuse plays an equally important role in Part II. The effort put into thinking abstractly about software structure and behavior pays off in high-level designs that prove useful independent of the application and implementation language. Patterns comprise reusable elements of successful designs.

The software community typically uses the terms “design patterns” and “object-oriented design patterns” interchangeably. This stems from the expressiveness of OOP languages in describing the relationships and interactions between ADTs. Patterns can improve a code's structure and readability and reduce its development costs by encouraging reuse.

Software design patterns comprise four elements (Gamma et al. 1995):

1. The pattern name: a handle that describes a design problem, its solution, and consequences in a word or two.

2. The problem: a description of when to apply the pattern and within what context.

3. The solution: the elements that constitute the design, the relationships between these elements, their responsibilities, and their collaborations.

4. The consequences: the results and trade-offs of applying the pattern.

Although there have been suggestions to include additional information in identifying a pattern, for example, sample code and known uses to validate the pattern as a proven solution, authors generally agree that elements 2-4 enumerate the three essential factors in each pattern.

The Problem

Large software development efforts typically require a degree of consistency across the project to ensure that each developer follows practices consistent with the critical goals of the project. In high-performance computing (HPC), for example, Amdahl's law (Chapter 1) suggests that scaling up to the tens or hundreds of thousands of processor cores available on leadership-class machines requires that every dusty corner of the code make efficient use of the available cores. Otherwise, whichever fraction of the code speeds up more slowly with increasing numbers of cores eventually determines the overall speedup of the code.

Another form of consistency proves useful when one desires some universal way to reference objects in a project. Doing so facilitates manipulating an object without knowledge of its identity. The manipulated object could equally well be an instance of any class in the project.

In HPC, communicating efficiently between local memories on distributed processors represents one of the most challenging problems. One might desire to ensure consistency in communication practices across the project. In these contexts, two broad requirements drive the desire to impose a degree of uniformity across a design: one stemming from a need for consistent functionality, and the other stemming from a need for consistent referencing.

Opposing these forces is the desire to avoid overconstraining the design. In the worst-case scenario, imposing too much uniformity stifles creativity and freezes counterproductive elements into the design.