\section{An Application of PAGS}
\label{sec:APPLY}
In this section, we describe our experiences
applying the PAGS framework to the solution of  
a grid simulation.
This application involves the solution of a common
class of grid problems that involve heartbeat or systolic
computations.  Traditionally, such problems are solved in
parallel by mapping grid-points, or clusters of points, onto
processes, then configuring the processes to communicate
according to the grid topology.  For many problems however,
this can lead to significant amounts of redundant and unnecessary
computation.  Furthermore, when grid topology is 
irregular or dynamic the traditional solution requires some
modifications to avoid idle processors.  
Such problems are easily mapped onto the PAGS framework.
To illustrate how this can be done we describe a 
4-point stencil-based successive over-relaxation (SOR)
problem which has regular, static topology.
Two Java implementations for this problem are sketched in Appendix A.
On the left side of the code in Section \ref{sec:sor-kernels} is
a sequential implementation in Java.  The triply-nested
loop is characteristic of this kind of convergence-based
2-dimensional finite-difference computation.
The right side of that Section shows the implementation
of the PAGS work object.  It is defined to represent dynamically-sized
partitions of a grid, called a {\tt SubGrid}.  
Note that the 2-dimensional computation kernel is almost
identical to the sequential version save for its loop bounds.
The outer loop in the {\tt doWork} computation allows
a {\tt SubGrid} to execute multiple simulation time steps
in isolation; this is only allowed when its neighboring
{\tt SubGrids} are running ahead in simulation time.

Section \ref{sec:sor-driver} illustrates the configuration
of the PAGS {\tt AssociativePool}, which is constructed with
a vector of {\tt SubGrid}s that have been initialized
in terms of their neighboring {\tt SubGrid}s and local data values.
The replicated worker abstraction is configured to execute
synchronously with no result processing.
The replicated workers object is created with {\tt numProcessors} workers
where each worker takes {\tt numIn} elements of work from the pool at a time.  
