CFD (Computational Fluid Dynamics) has been a major motivator for much algorithm and software work in HPCC, and indeed extensions of HPF have largely been based on CFD (or similar partial differential equation based applications) and molecular dynamics [Bogucz:94a], [Choudhary:92d;94c], [Dincer:95b],
[Goil:94a;95a], [Hawick:95a;95b],
, [HPF:94a]. Partial differential equations
can be quite straightforward on parallel machines if one uses regular
grids, such as those coming from the simplest finite difference
equations. However, modern numerical methods use either finite
elements or a refinement strategy for finite elements, which gives rise
to irregular meshes. Approaches, such as domain decomposition and
multigrid, also give use to complex data structures. From a Fortran
programmer's point of view, simple finite differences can be well
described by Fortran array data structures. Corresponding
parallelization of such applications is well suited to the current HPF
language, which is centered in decomposing arrays. All the more
advanced partial differential equation schemes naturally need somewhat
more sophisticated (than simple arrays) data structures, including
arrays of pointers, linked lists, nested arrays, and complex trees.
The latter are also seen in fast multipole particle dynamics problems,
as well as fully adaptive PDE's [Edelsohn:91b]. Some excellent
methods, such as the Berger-Oliger adaptive mesh refinement
[Berger:84a] require modest HPF extensions as we have shown in our
Grand Challenge work on colliding black holes [Haupt:95a].
However, as Saltz's group has shown in a set of pioneering projects
[HPF:94a], many important PDE methods require nontrivial HPF
language extensions, as well as sophisticated runtime support, such as
the PARTI [Saltz:91b] and CHAOS systems [Edjali:95a],
[Hwang:94a], [Ponnusamy:93c;94b].
The needed language support can be thought of
as expressing the problem architecture (computational graph as in
Figure 
(a), which is only implicitly defined by the
standard (Fortran) code. Correctly written, this vanilla Fortran
implies all needed information for efficient parallelism. However,
this information is realized in terms of the values of pointers and
cannot be recognized at compile time for either static or compiler
generated dynamic runtime parallelism. This fundamental problem is of
course why Fortran is a more successful parallel language than C as
latter naturally uses pointer constructs that obscure the problem
architecture even more. The runtime support for PDE's must cope with
irregular and hierarchical meshes and provide the dynamic alignment
decomposition and communications optimization that HPF provides for
arrays.
We now move from CFD to manufacturing, or rather design and manufacturing, which metaproblem includes CFD as a subarea. Manufacturing is particularly interesting, as it needs all aspects of the HPCC initiative from powerful computational engines, huge databases to pervasive secure high-performance networks. Now we use the word ``manufacturing'' in its broadest sense to include design, the actual processes that build the product, and the full life cycle maintenance. HPCC has a natural high profile role in implementing the popular concept of agile manufacturing, which supposes the model where virtual corporations generate ``products-on-demand.'' The NII is used to link collaborating organizations. HPCC is needed to support instant design (or more accurately redesign or customization) and sophisticated visualization and virtual reality ``test drives'' for the customer. At the corporate infrastructure level, concurrent engineering involves integration of the different component disciplines---such as design, manufacturing, and product life cycle support---involved in engineering. These general ideas are tested severely when they are applied to the design and manufacturing of complex systems such as automobiles, aircraft, and space vehicles such as shuttles. Both the complexity of these products, and in some sense the maturity of their design, places special constraints and challenges on HPCC.
High-performance computing is important in all aspects of the design of a new aircraft. However, it is worth noting that it has been estimated that less than 5% of the initial costs of the Boeing 777 aircraft were incurred in computational fluid dynamics (CFD) airflow simulations---the ``classic'' Grand Challenge in this field described above. On the other hand, over 50% of these sunk costs could be attributed to overall systems issues. Thus, it is useful but not sufficient to study parallel computing for large scale CFD. This is ``Amdahl's law for practical HPCC.'' If only 5% of a problem is parallelized, one can at best speed up and impact one's goals---affordability, time to market---by this small amount. HPCC, thus, must be fully integrated into the entire engineering enterprise to be effective. Very roughly, we can view the ratios of 5% to 50% as a measure of ratio of 1:10 of the relevance of parallel and distributed computing in this case, or alternatively as the ratio of ``old style'' to ``new style'' HPCC.
The maturity of the field is illustrated by the design criterion used today. In the past, much effort has been spent on improving performance---more speed, range, altitude, size. These are still critical under extreme conditions, but basically these just form a given design framework that suffices to buy you a place at the table (on the short-list). Rather, the key design criteria is competitiveness, including time to market, and total affordability. Although the design phase is not itself a major cost item, decisions made at this stage lock in most of the full life cycle cost of an aircraft with perhaps 80% of total cost split roughly equally between maintenance and manufacturing. Thus, it certainly would be important to apply HPCC at the design phase to both shorten the design cycle (time to market) and lower the later ongoing costs of manufacturing and maintenance.
We take as an example the design of a future military aircraft---perhaps 10 years from now. This analysis is taken from a set of NASA sponsored activities centered on a study of ASOP---Affordable Systems Optimization Process. This involved an industrial team, including Rockwell International, Northrop Grumman, McDonnell Douglas, General Electric, and General Motors. ASOP is one of several possible approaches to multidisciplinary analysis and design (MAD) and the results of the study should be generally valid to these other MAD systems. The hypothetical aircraft design and construction project could involve six major companies and 20,000 smaller subcontractors. This impressive virtual corporation would be very geographically dispersed on both a national and probably international scale. This project could involve some 50 engineers at the first conceptual design phase. The later preliminary and detailed design stages could involve 200 and 2,000 engineers, respectively. The design would be fully electronic and demand major computing, information systems, and networking resources. For instance, some 10,000 separate programs would be involved in the design. These would range from a parallel CFD airflow simulation around the plane to an expert system to plan location of an inspection port to optimize maintainability. There is a corresponding wide range of computing platforms from PCs to MPPs and a range of languages from spreadsheets to high-performance Fortran. The integrated multidisciplinary optimization does not involve blindly linking all these programs together, but rather a large number of suboptimizations involving at one time a small cluster of these base programs. Here we see clearly, an essential role of HPCC to implement these optimizations, that could well need linking of geographically separated compute and information systems. An aircraft is, of course, a very precise system, which must work essentially flawlessly. This requirement implies a very strict coordination and control of the many different components of the aircraft design. Typically, there will be a master systems database to which all activities are synchronized at regular intervals--perhaps every month. The clustered suboptimizations represent a set of limited excursions from this base design that are managed in a loosely synchronous fashion on a monthly basis. The configuration management and database system are both critical and represent a major difference between manufacturing and command and control, where in the latter case, real time ``as good as you can do'' response, is more important than a set of precisely controlled activities. These issues are characteristic of the linkage of HPCC, and the NII where, although loosely coupled, the computers on our global network are linked to ``solve a single problem.''
ASOP is designed as a software backplane (the NII) linking eight major
services or modules shown in Figure . These are design
(process controller) engine, visualization, optimization engine,
simulation engine, process (manufacturing, productibility,
supportability) modeling toolkit, costing toolkit, analytic modeling
toolkit, and geometry toolkit. These are linked to a set of databases
defining both the product and also the component properties. Parallel
computing is important in many of the base services, but the linkage of
NII, and HPCC technologies is seen in the full system. Using compute
enhanced Web Technology (such as, WebWork [Fox:95a] in such
systems is natural because one has the mix of geographically
distributed people/computers needing both data and simulation
services.
Figure: Affordable Systems Optimization Process (ASOP) Implemented on the
NII for Aeronautics Systems