Subject: ParkBench compact applications

From: [email-masked] (David Walker)
Date: Thu, 14 Oct 1993 13:37:27 -0400

Mike,
	Below is the latest version of the Compact Application section of the
ParkBench document. I also intend to send a latex version of the submission 
form to you later today for inclusion as Appendix A. I hope there will
be some comments back from the other members of teh subcommittee about
this section so I hope there will be an opportunity to update it.

David
%file: compac3.tex
%date: October 14, 1993
\chapter{Compact Applications}
\footnote{assembled by David Walker for Compact Applications subcommittee}

\section{Introduction}
\label{sec:compact.intro}
While kernel applications, such as those described in Chapter 3, provide
a fairly straightforward way of assessing the performance of parallel
systems they are not representative of scientific applications in general
since they do not reflect certain types of system behavior. In particular,
many scientific applications involve data movement between phases of
an application, and may also require significant amounts of I/O. These types
of behavior are difficult to gauge using kernel applications. 

One factor
that has hindered the use of full application codes for benchmarking parallel
computers in the past is that such codes are difficult to parallelize and to
port between target architectures. In addition, full application codes that
have been successfully parallelized are often proprietary, and/or subject
to distribution restrictions. To minimize the negative impact of these factors
we propose to make use of compact applications in our benchmarking effort.

Compact applications are typical of those found in research environments 
(as opposed to production or engineering environments), and usually consist of 
up to a few thousand lines of source code. Compact applications are distinct 
from kernel applications since they are capable of producing scientifically
useful results. In many cases, compact applications are made up of several
kernels, interspersed with data movements and I/O operations between the 
kernels.

In this chapter the criteria for selecting compact applications
for the ParkBench suite will be discussed. In addition, the general 
research areas that will be represented in the suite are outlined.

%In this chapter we will discuss a number of compact applications in terms of 
%their purpose, the algorithms used, the types of data movements required, 
%the memory requirements, and
%the amount of I/O. The compact application below are not meant to form a 
%definite or complete list.

\section{Criteria for Selection}
\label{sec:criteria}
The three main criteria for inclusion of a parallel code
in the Compact Applications suite are,
\begin{enumerate}
\item
The code must be a complete application and be capable of producing results
of research interest. These two points distinguish a compact application from
a kernel. For example, a code that only solves a randomly-generated, dense, 
linear system by LU factorization should be considered a kernel. Even though 
the code is complete, it does not produce results of research interest. 
However, if the LU factorization is embedded in an application that uses
the boundary element method to solve, for example, a two-dimensional
elastodynamics problem, then such an application could legitimately be
considered a compact application. 
Compact applications and full production codes are distinguished by their
software complexity, which is difficult to quantify. Software complexity gives
an indication of how hard it is to write, port and maintain an application, 
and may be gauged very roughly by the length of the source code. However, there
is no hard upper limit on the length of a code in the Compact Applications 
suite.  It is expected that the source code (excluding comments and repeated 
common blocks) for most compact applications will be between 2000 and 10000 
lines, but some may be longer.

\item
The code must be of high quality. This means it must have been extensively
tested and validated, preferably on a wide selection of different parallel
architectures. The problem size and number of processors used must not be
hard-coded into the application, and should be specified at runtime as input 
to the program. Ideally, the parallel code should not impose restrictions on 
the problem size that are not applicable for the corresponding sequential code.
Thus, the parallel code should not require that the problem size be exactly 
divisible by the number of processors, or that the number of processors be 
a power of two. In some cases this latter requirement may have to be relaxed.
For example, most parallel fast Fourier transform routines require the number
of processors to be a power of two. It is preferable that the code be
written so that it works correctly for
an arbitrary one-to-one mapping between the logical process topology of the
application and the hardware topology of the parallel computer.
This is desirable so
that the assignment of a location in the logical process topology to a
physical processor can be easily adjusted when porting
the application between platforms. For example a Gray code assignment may
be best for a hypercube, and a natural ordering for a mesh architecture.

\item
The application must be well documented. The source code itself should 
contain an adequate number of comments, and each module should begin
with a comment section that describes what the routine does, and the
arguments passed to it. In addition, there should be a ``Users' Guide''
to the application that describes the input and output, the parameterization
of the problem size and processor layout, and details of what the application
does. The Users' Guide should also contain a bibliography of related
papers.
\end{enumerate}

In addition, to the three criteria discussed above, there are a number of
other desirable features that a ParkBench Compact Application should have.
These are discussed in the following subsections.

\subsection{Self Checking Applications}
\label{subsec:checking}
The application should be self-checking. That is, at the end of the computation
the application should perform a check to validate the results of the run.
The application may also output a summary of performance results for the run,
such as the Mflop rate, and other pertinent information.

\subsection{Programming Languages}
\label{subsec:languages}
The code should be written in Fortran 77, Fortran 90, High Performance Fortran,
or C. Data should be passed between processors by explicit message passing.
ParkBench does not specify which message passing system should be used, but
one that is available on a number of parallel platforms is preferable. 
Eventually it is expected that MPI will become the message passing system
of choice, but in the meantime portable systems such as PVM, PICL, Express,
PARMACS, and P4 are acceptable alternatives. The codes in the
Compact Applications suite should not contain any assembly coded portions,
although assembly code may be used in optimized versions of the code.

\section{Proposed Compact Application Benchmarks}
\label{sec:compact.proposed}
At the time of writing (October 1993) the ParkBench organization is in
the process of soliciting submission of applications for inclusion in
the Compact Applications suite. Thus, the applications that comprise the suite
cannot yet be listed here. However, in this section the main application areas
that are expected to be in the suite are outlined. The intention is that
these areas should be representative of the fields in which parallel
computers are actually used. The codes should exercise a number of different
algorithms, and possess different communication and I/O characteristics.
Initially the Compact Applications suite will
consist of no more than ten codes. This restriction is imposed so that
the resources needed to manage and distribute the suite can be assessed. The
suite may be enlarged in the future if this seems manageable.
Below is a list of the application areas that are expected to be
represented in the suite. This is
not meant to be an exclusive list; submissions from other application areas
will be considered for inclusion in the suite.
\begin{itemize}
\item
Climate and meteorological modeling
\item
Computational fluid dynamics (CFD)
\item
Finance, e.g., portfolio optimization
\item
Molecular dynamics
\item
Plasma physics
\item
Quantum chemistry
\item
Quantum chromodynamics (QCD)
\item
Reservoir modeling
\end{itemize}

\section{Submitting to the Compact Application Suite}
\label{sec:submit}
The procedure for submitting codes to the ParkBench Compact Applications suite
is as follows.
\begin{enumerate}
\item
Complete the submission form in Appendix A, and email it to David Walker
at [email-masked]. The data on this form will be reviewed
by the ParkBench Compact Applications Subcommittee, and the submitter will
be notified if the application is to be considered further for
inclusion in the ParkBench suite.
\item
If ParkBench Compact Applications Subcommittee decides to consider
the application further the submitter will be asked to submit the source code
and input and output files, together with any documentation and papers
about the application. Source code and input and output files should
be submitted by email, or ftp, unless the files are very large, in
which case a tar file on a 1/4 inch cassette tape. Wherever possible
email submission is preferred for all documents in man page, Latex
and/or Postscipt format. These files documents and papers together
constitute the application package. The application package should
be sent to the following address, and the subcommittee will then make a final 
decision on whether to include the application in the ParkBench suite.\par
\smallskip
\indent David W. Walker\par
\indent Oak Ridge National Laboratory\par
\indent Bldg.~6012/MS-6367\par
\indent P. O. Box 2008\par
\indent Oak Ridge, TN 37831-6367\par
\indent (615) 574-7401/0680 (phone/fax)\par
\indent [email-masked]\par

\item
If the application is approved for inclusion in the ParkBench suite
an authorized person from the submitting organization will be asked
to complete and sign a form giving ParkBench authority to distribute,
and modify (if necessary), the application package.