\documentstyle[]{csart}
\begin{document}

\title{Puma 6 Month Technical Report\\WP5.1 - QCD}
\author{D.B. Carpenter}
\address{University of Southampton}
\date{January 29th, 1990}

\maketitle{}

     The aims of this task are to study a particular scientific
application of massively parallel computers, namely Quantum
Chromodynamics (QCD).  Also to provide a library of (high-level) 
communications
primitives for present and forthcoming transputer-based machines,
supporting patterns of communications characteristic of this
and analogous array-oriented problems.

     In collaboration with Prof. C.J. Sachrajda (Dept. of Physics,
Southampton) we will investigate properties of "heavy-quark" systems,
initially by simulation on the 128-transputer Telmat Meganode located
at Southampton's Transputer Support System.  Later on we expect
to transfer the software to PUMA-funded hardware.

     The first few months of the project have been engaged in
"scaling up" existing QCD software (developed largely under
Esprit P1085 project) to permit simulation of the very large
systems needed for competitive research in this area.

     Three main problems of a technical nature that have arisen
so far are 

\begin{enumerate}
  \item The small amount memory on the target hardware,
  \item the relatively small amount of mass storage
on the host computer (a SUN 3/180), and
  \item IO bandwidth limitations between the transputer array and the
host computer.
\end{enumerate}

\section{Memory Limitations}

     The Meganode
we are using only has 256K memory on each processor, giving a
total distributed memory of 32Mbytes.  The minimum lattice
size considered necessary for these problems is around
$16^3$ by $40$ (this lattice being the multi-dimensional grid
on which the problem is discretised for purposes of numerical
analysis).  Fitting this size system onto the machine has
involved various compromises in which execution speed was
traded off to reduce memory requirements - for example
inversion of the a sparse matrix, which is the core
of the numerical work, is performed by relatively slow naive
red-black relaxation, rather than using a faster but more
memory-intensive algorithm such as conjugate gradients (it may
be possible to improve performance at a later stage by using
some acceleration scheme, such as multigrid).  

     Additionally it will probably prove necessary to store
intermediate results on some mass storage unit, rather than
in fast memory.  This issue brings us to problems 2 and 3.

\section{Mass storage}

     We will need to store many large vectors of intermediate
results, generated by the simulation program, and read later
by analysis programs.  Each vector contains around 16Mbytes of
data.

     The intention is to store this data on exabyte tape.
There will be too much data to store in the available host disk
space.  Thus we need the capability to write data "directly"
from a program running on the transputer array to the host's
exabyte driver.  Unfortunately this was not possible with
existing transputer "server" software running on the Sun 
('iserver', 'server14', etc).

\section{IO bandwith}
 
     For the reasons above we need quite fast data transfer between
the transputer network and the host computer.  The interface between
the two in the target hardware is a Niche NT1000 Sun-resident transputer
card.  This supports data transfer at rates around 1Mbyte/s,
which is probably adequate for our purposes.  However it was perceived
that existing inmos-derived servers would probably not be able
to exploit this bandwidth fully, mainly because their link protocols
enforce transmission of data
in relatively small packets, whereas the UNIX driver software
for the NT1000 is most efficient when transferring quite large packets.
\hfill\break

     For reasons 2 and 3 above it was considered necessary to
implement a reduced file server program ('qserver'), optimised
for high speed access to general UNIX files, assuming the SUN/NT1000
hardware configuration.  The programs are currently developed under
the inmos TDS system, but run in "standalone" mode using 'qserver'.

     The current software has been implemented using communication
software developed under Esprit P1085, with only minor improvements.
At a later stage we intend to implement enhanced
versions of these communication routines, with more general usefulness.
\hfill\break

     In summary, although it will be possible to run our application
on the available hardware, it would be advantageous to have available
a system with considerably more memory (and, ideally, more directly
accessable mass storage capacity).
Early indications are that the speed of our Meganode program is similar to
that of a CRAY XMP, where related applications are currently
running.
Increased memory would allow adoption of somewhat faster algorithms.

\end{document}

