In understanding the role of the web in large-scale simulations, it is useful to classify the various forms of concurrency in problems into four types [5].
This is illustrated by natural parallelism over the particles in a molecular dynamics computation; over the grid points in a partial differential equation; over the random points in a Monte Carlo algorithm. In the Web computation of the factors of RSA130 [7], we can consider the parallelism over possible trials in the Sieve algorithm as the ``data'' for data parallelism in this application. Data parallelism tends to be ``massive'' because computations are typically time consuming due to a large amount of data. Thus, data parallelism is parallelism over what is ``large'' in the problem. It is not difficult to find data parallel problems today with parallelism measured in the millions (e.g., a grid) and by the year 2007, billion-way data parallelism can be expected.
Here we are thinking of typical thread parallelism, such as the overlap of computation (say, decompressing an image) and communication (fetching HTML from a server). More generally, problems typically support overlap of I/O (disk, visualization) with computation. We also, of course, can have multiple compute tasks executing concurrently. This form of parallelism is present in most problems; the units are modest grain size (larger than a few instructions scheduled by a compiler, smaller than an application), and typically not massively parallel. Further, such functional parallelism is typically implemented using a shared memory and, indeed, its existence in most problems makes few way parallel shared memory multiprocessors very attractive.
We could mean many things by this, but we have in mind the type of problems solved by discrete event simulators. These are illustrated by military simulations where the objects are ``vehicles,'' ``weapons,'' or ``humans in the loop.'' The well-known SIMNET or DSI (Distributed simulation Internet) have already illustrated the relevance of distributed (Internet) technology for this problem class [8]. Object descriptions are similar to data parallelism except that the fundamental units of parallelism, namely objects are quite large, corresponding to a macroscopic description of an application. Thus, a military battle is described in terms of the units of force (tanks, soldiers) with phenomenological interactions rather than in (unrealistic in this case) fundamental description in terms of atomic particles or finite element nodes. For a typical ``data parallel'' problem, the fundamental units of parallelism (grid points) are typically smaller.
This is another functional concurrency, but now with large-grain size components. In image processing, one often sets up an analysis system where the pixels are processed by a set of separate filters--each with a different convolution or image understanding algorithms. Software systems, such as AVS and Khoros are well-known tools to support such linked modules. So a metaproblem is a set of linked problems (databases, computer programs) where each unit is essentially a complete problem itself. Dataflow (a graph specifying how problems accept data from previous steps and produce data for further processing) is a successful paradigm for metaproblems. In manufacturing, one often sees metaproblems as building a complex system, such as an aircraft, requiring linking airflow, controls, manufacturing process, acoustic, pricing and structural analysis simulations. It has been estimated that designing a complete aircraft could require some 10,000 separate programs--some complicated ones such as airlow simulation were mentioned above, but as well there are simpler but critical expert systems to locate inspection ports, and other life-cycle optimization issues [3], [4]. Metaproblems have concurrency that it typically quite modest. They differ from the examples, in category 2 above, in that the units have larger grain size and are more self contained. This translates into different appropriate computer architectures. Modest grain size functional parallelism (2) needs low latency and high bandwidth communication--typically implemented with a shared memory. Metaproblems are naturally implemented in a distributed (Web) environment--latency is often unimportant while needed network bandwidths are more variable.