Diff of /manual/s_software/text/sarch.tex

Parent Directory | Revision Log | Revision Graph | Patch

--- manual/s_software/text/sarch.tex	2006/04/04 15:54:55	1.21
+++ manual/s_software/text/sarch.tex	2006/04/04 18:33:52	1.22
@@ -1,20 +1,20 @@
-% $Header: /home/ubuntu/mnt/e9_copy/manual/s_software/text/sarch.tex,v 1.21 2006/04/04 15:54:55 edhill Exp $
+% $Header: /home/ubuntu/mnt/e9_copy/manual/s_software/text/sarch.tex,v 1.22 2006/04/04 18:33:52 edhill Exp $
 
-This chapter focuses on describing the {\bf WRAPPER} environment within which
-both the core numerics and the pluggable packages operate. The description
-presented here is intended to be a detailed exposition and contains significant
-background material, as well as advanced details on working with the WRAPPER. 
-The tutorial sections of this manual (see sections
-\ref{sect:tutorials}  and \ref{sect:tutorialIII}) 
-contain more succinct, step-by-step instructions on running basic numerical
-experiments, of varous types, both sequentially and in parallel. For many 
-projects simply starting from an example code and adapting it to suit a 
-particular situation 
-will be all that is required.
-The first part of this chapter discusses the MITgcm architecture at an 
-abstract level. In the second part of the chapter we described practical 
-details of the MITgcm implementation and of current tools and operating system 
-features that are employed.
+This chapter focuses on describing the {\bf WRAPPER} environment
+within which both the core numerics and the pluggable packages
+operate. The description presented here is intended to be a detailed
+exposition and contains significant background material, as well as
+advanced details on working with the WRAPPER.  The tutorial sections
+of this manual (see sections \ref{sect:tutorials} and
+\ref{sect:tutorialIII}) contain more succinct, step-by-step
+instructions on running basic numerical experiments, of varous types,
+both sequentially and in parallel. For many projects simply starting
+from an example code and adapting it to suit a particular situation
+will be all that is required.  The first part of this chapter
+discusses the MITgcm architecture at an abstract level. In the second
+part of the chapter we described practical details of the MITgcm
+implementation and of current tools and operating system features that
+are employed.
 
 \section{Overall architectural goals}
 \begin{rawhtml}
@@ -25,19 +25,19 @@
 three-fold
  
 \begin{itemize}
-\item We wish to be able to study a very broad range
-of interesting and challenging rotating fluids problems.
-\item We wish the model code to be readily targeted to
-a wide range of platforms
-\item On any given platform we would like to be
-able to achieve performance comparable to an implementation 
-developed and specialized specifically for that platform.
+\item We wish to be able to study a very broad range of interesting
+  and challenging rotating fluids problems.
+\item We wish the model code to be readily targeted to a wide range of
+  platforms
+\item On any given platform we would like to be able to achieve
+  performance comparable to an implementation developed and
+  specialized specifically for that platform.
 \end{itemize}
 
-These points are summarized in figure \ref{fig:mitgcm_architecture_goals} 
-which conveys the goals of the MITgcm design. The goals lead to
-a software architecture which at the high-level can be viewed as consisting 
-of
+These points are summarized in figure
+\ref{fig:mitgcm_architecture_goals} which conveys the goals of the
+MITgcm design. The goals lead to a software architecture which at the
+high-level can be viewed as consisting of
 
 \begin{enumerate}
 \item A core set of numerical and support code. This is discussed in
@@ -71,14 +71,13 @@
 \begin{center}
 \resizebox{!}{2.5in}{\includegraphics{part4/mitgcm_goals.eps}}
 \end{center}
-\caption{
-The MITgcm architecture is designed to allow simulation of a wide 
-range of physical problems on a wide range of hardware. The computational 
-resource requirements of the applications targeted range from around 
-$10^7$ bytes ( $\approx 10$ megabytes ) of memory to $10^{11}$ bytes
-( $\approx 100$ gigabytes). Arithmetic operation counts for the applications of 
-interest range from $10^{9}$ floating point operations to more than $10^{17}$ 
-floating point operations.}
+\caption{ The MITgcm architecture is designed to allow simulation of a
+  wide range of physical problems on a wide range of hardware. The
+  computational resource requirements of the applications targeted
+  range from around $10^7$ bytes ($\approx 10$ megabytes) of memory to
+  $10^{11}$ bytes ($\approx 100$ gigabytes). Arithmetic operation
+  counts for the applications of interest range from $10^{9}$ floating
+  point operations to more than $10^{17}$ floating point operations.}
 \label{fig:mitgcm_architecture_goals}
 \end{figure}
 
@@ -87,19 +86,20 @@
 <!-- CMIREDIR:wrapper: -->
 \end{rawhtml}
 
-A significant element of the software architecture utilized in
-MITgcm is a software superstructure and substructure collectively
-called the WRAPPER (Wrappable Application Parallel Programming 
-Environment Resource). All numerical and support code in MITgcm is written 
-to ``fit'' within the WRAPPER infrastructure. Writing code to ``fit'' within 
-the WRAPPER means that coding has to follow certain, relatively
-straightforward, rules and conventions (these are discussed further in 
+A significant element of the software architecture utilized in MITgcm
+is a software superstructure and substructure collectively called the
+WRAPPER (Wrappable Application Parallel Programming Environment
+Resource). All numerical and support code in MITgcm is written to
+``fit'' within the WRAPPER infrastructure. Writing code to ``fit''
+within the WRAPPER means that coding has to follow certain, relatively
+straightforward, rules and conventions (these are discussed further in
 section \ref{sect:specifying_a_decomposition}).
 
-The approach taken by the WRAPPER is illustrated in figure 
-\ref{fig:fit_in_wrapper} which shows how the WRAPPER serves to insulate code 
-that fits within it from architectural differences between hardware platforms 
-and operating systems. This allows numerical code to be easily retargetted. 
+The approach taken by the WRAPPER is illustrated in figure
+\ref{fig:fit_in_wrapper} which shows how the WRAPPER serves to
+insulate code that fits within it from architectural differences
+between hardware platforms and operating systems. This allows
+numerical code to be easily retargetted.
 
 
 \begin{figure}
@@ -416,16 +416,17 @@
 \subsection{Distributed memory communication}
 \label{sect:distributed_memory_communication}
 Many parallel systems are not constructed in a way where it is
-possible or practical for an application to use shared memory
-for communication. For example cluster systems consist of individual computers
-connected by a fast network. On such systems there is no notion of shared memory
-at the system level. For this sort of system the WRAPPER provides support
-for communication based on a bespoke communication library 
-(see figure \ref{fig:comm_msg}).  The default communication library used is MPI 
-\ref{mpi}. However, it is relatively straightforward to implement bindings to 
-optimized platform specific communication libraries. For example the work 
-described in \ref{hoe-hill:99} substituted standard MPI communication for a 
-highly optimized library.
+possible or practical for an application to use shared memory for
+communication. For example cluster systems consist of individual
+computers connected by a fast network. On such systems there is no
+notion of shared memory at the system level. For this sort of system
+the WRAPPER provides support for communication based on a bespoke
+communication library (see figure \ref{fig:comm_msg}).  The default
+communication library used is MPI \cite{MPI-std-20}. However, it is
+relatively straightforward to implement bindings to optimized platform
+specific communication libraries. For example the work described in
+\ref{hoe-hill:99} substituted standard MPI communication for a highly
+optimized library.
 
 \subsection{Communication primitives}
 \label{sect:communication_primitives}