\begin{flushleft}
{\bf 7. Portability Issues}
\end{flushleft}

Almost all  studies  reporting results  on  parallel  and  distributed
computing focus  on the changes that  had to be made in the program to
achieve speed-ups on a particular system.   In moving the same program
between a number of different systems, it was discovered that there is
a  significant  difference  between a  portable  piece of  code and  a
portable application.  In  this context, ``application''  includes not
only  the  program  code,  but  also  the  development  and  execution
environment,  as  well as  input and  output  data sets.  This section
briefly discusses some of the porting problems encountered when moving
air quality models between different architectures.  These issue apply
to environmental  models in general,  and they outline the tasks  that
will  have  to  be  tackled  when  adapting  programs  to  give  users
transparent access to a wide range of computing resources.

One  major issue is the difference in the development environments for
different architectures.  Different  systems  use  different compilers
(for   example,   different   switches  to   control  the   level   of
optimization),  debuggers,  and  often  different  versions  of common
utilities as well as libraries such as PVM.  None  of these issues are
of course fundamental, but they make porting more  difficult.  One way
to deal with some of these differences is to use compiler switches for
different architectures;  however, differences such  as  the debugging
environment cannot be addressed in this manner.

Another  issue  is  the  difference  in  the  execution  environments.
Although  interactive  execution  is  possible   for  debugging,  most
executions  are done in batch mode,  using  different queueing systems
(e.g. NQS  on the Cray  C90 and DQS on the PSC  Alpha  cluster).   The
biggest difference, however, is in how I/O is handled.  In most cases,
the input and output  data are stored remotely, and moving the data in
a reliable, secure  and  efficient way  is  often  very site-specific.
Also,  when executing  on  remote systems, a number  of  problems  can
occur, including problems with authentication and  the  allocation  of
resources  such  as memory and  disk space.  Detecting and  recovering
from these  problems in a portable way is very difficult, and requires
a complex and robust control strategy.

Thus,  to  develop a  truly portable  application,  what  is needed is
availability  of uniform compilation and  execution environment on the
various  parallel  computation  platforms  currently in use.   For the
present  application, portability  is  achieved through  the  use of a
variety     of     techniques     including,     architecture-specific
Makefile\footnote{``make''   is  a   Unix   utility   that   maintains
relationships among files. It is normally used for compiling programs,
but  we  also use  it for  selecting  and maintaining compilation  and
execution options.} definitions and system-specific  execution scripts
which use various compilation switches that account for differences in
systems.