There is no agreed-upon process behind computation, that is, behind the use of a computer to solve a particular problem. We have tried to quantify this in Figures 3.1(b), 3.2(b), and 3.3 which show a problem being first numerically formulated and then mapped by software onto a computer.

**Figure 3.3:** An Interdisciplinary Approach to Computing with Computational
Science Shown Shaded

Even if we could get agreement on such an ``underlying'' process, the
definitions of the parts of the process are not precise and correspondingly
the roles of the ``experts'' are poorly defined. This underlies much of the
controversy, and in particular, why we cannot at present or probably ever
be able to define
*``The best software methodology for parallel computing.''*

How can we agree on a solution (What is the appropriate software?) unless we can agree on the task it solves?

In other words, what is the underlying process?``What is computation and how can it be broken up into components?''

In spite of our pessimism that there is any clean, precise answer to this question, progress can be made with an imperfect process defined for computation. In the earlier figures, it was stressed that software could be viewed as mapping problems onto computers. We can elaborate this as shown in Figure 3.4, with the solution to a question pictured as a sequence of idealizations or simplifications which are finally mapped onto the computer. This process is spelled out for four examples in Figures 3.5 and 3.6. In each case, we have tried to indicate possible labels for components of the process. However, this can only be approximate. We are not aware of an accepted definition for the theoretical or computational parts of the process. Again, which parts are modelling or simulation? Further, there is only an approximate division of responsibility among the various ``experts''; for example, between the theoretical physicist and the computational physicist, or among aerodynamics, applied mathematics, and computer science. We have also not illustrated that, in each case, the numerical algorithm is dependent on the final computer architecture targeted; in particular, the best parallel algorithm is often different from the best conventional sequential algorithm.

**Figure 3.4:** An Idealized Process of Computation

**Figure 3.5:** A Process for Computation in Two Examples in Basic Physics
Simulations

**Figure 3.6:** A Process for Computation in Two Examples from Large Scale
System Simulations

We can abstract Figures 3.5 and 3.6 into a sequence of maps between complex systems , .

We have anticipated (Chapter 5) and broken the software into a high level component (such as a compiler) and a lower level one (such as an assembler) which maps a ``virtual computer'' into the particular machine under consideration. In fact, the software could have more stages, but two is the most common case for simple (sequential) computers.

A complex system, as used here, is defined as a collection of fundamental
entities whose static or dynamic properties define a connection scheme
between the entities. Complex systems have a structure or architecture.
For instance, a binary hypercube parallel computer of dimension **d** is
a complex system with members connected in a hypercube
topology. We can focus in on the node of the hypercube and expand the
node, viewed itself as a complex system, into a collection of memory
hierarchies, caches, registers, CPU., and communication channels. Even
here, we find another ill-defined point with the complex system representing
the computer dependent on the resolution or granularity with which you
view the system. The importance of the architecture of a computer
system has been recognized for many years. We suggest
that the architecture or structure of the problem is comparably
interesting. Later, we will find that the performance of a particular
problem or machine can be studied in terms of the match (similarity)
between the architectures of the complex systems and
defined in Equation 3.1. We will find
that the structure of the appropriate parallel software will depend on
the broad features of the (similar) architecture of and
. This can be expected as software maps the two
complex systems into each other.

At times, we have talked in terms of problem architecture, but this is ambiguous since it could refer to any of the complex systems which can and usually do have different architectures. Consider the second example of Figure 3.5 with the computational fluid dynamics study of airflow. In the language of Equation 3.1:

- is a (finite) collection of molecules interacting with
long-range Van der Waals and other forces. This interaction defines a
complete interconnect between all members of the complex system .
- is the infinite degree of freedom continuum with the fundamental
entities as infinitesimal volumes of air connected locally by the partial
differential operator of the Navier Stokes equation.
- could depend on the particular numerical
formulation used. Multigrid, conjugate gradient , direct matrix inversion and alternating gradient would have
very different structures in the direct numerical solution of the
Navier Stokes equations. The more radical cellular
automata approach would be quite different
again.
- would depend on the final computer being used
and division between high and low level in software. In the applications
described in this book, would typically be a simple binary hypercube
with nodes.
- would be embroidered by the
details of the hardware communication (circuit or packet switching, wormhole
or other routing). Further, as described above, in some analyses we could
look at this complex system in greater resolution and expose the details of
the processor node architecture.

Wed Mar 1 10:19:35 EST 1995