--- manual/s_software/text/sarch.tex	2004/01/29 15:39:49	1.15
+++ manual/s_software/text/sarch.tex	2004/03/23 15:29:40	1.17
@@ -1,4 +1,4 @@
-% $Header: /home/ubuntu/mnt/e9_copy/manual/s_software/text/sarch.tex,v 1.15 2004/01/29 15:39:49 afe Exp $
+% $Header: /home/ubuntu/mnt/e9_copy/manual/s_software/text/sarch.tex,v 1.17 2004/03/23 15:29:40 afe Exp $
 
 This chapter focuses on describing the {\bf WRAPPER} environment within which
 both the core numerics and the pluggable packages operate. The description
@@ -76,6 +76,9 @@
 \end{figure}
 
 \section{WRAPPER}
+\begin{rawhtml}
+<!-- CMIREDIR:wrapper -->
+\end{rawhtml}
 
 A significant element of the software architecture utilized in
 MITgcm is a software superstructure and substructure collectively
@@ -150,6 +153,9 @@
 computer architecture currently available to the scientific computing community.
 
 \subsection{Machine model parallelism}
+\begin{rawhtml}
+<!-- CMIREDIR:domain_decomp -->
+\end{rawhtml}
 
  Codes operating under the WRAPPER target an abstract machine that is assumed to
 consist of one or more logical processors that can compute concurrently.  
@@ -1267,7 +1273,9 @@
 the cube-sphere grid. In this class of grid a rotation may be required
 between tiles. Aligning the coordinate requiring rotation with the
 tile decomposition, allows the coordinate transformation to 
-be embedded within a custom form of the \_EXCH primitive.
+be embedded within a custom form of the \_EXCH primitive.  In these
+cases \_EXCH is mapped to exch2 routines, as detailed in the exch2
+package documentation  \ref{sec:exch2}.
 
 \item {\bf Reverse Mode}
 The communication primitives \_EXCH and \_GSUM both employ 
@@ -1284,6 +1292,7 @@
 is set to the value {\em REVERSE\_SIMULATION}. This signifies 
 ti the low-level routines that the adjoint forms of the
 appropriate communication operation should be performed.
+
 \item {\bf MAX\_NO\_THREADS}
 The variable {\em MAX\_NO\_THREADS} is used to indicate the
 maximum number of OS threads that a code will use. This
@@ -1388,7 +1397,7 @@
 This is done to allow a large number of variations on the exchange 
 process to be maintained. One set of variations supports the
 cube sphere grid. Support for a cube sphere grid in MITgcm is based
-on having each face of the cube as a separate tile (or tiles).
+on having each face of the cube as a separate tile or tiles.
 The exchange routines are then able to absorb much of the
 detailed rotation and reorientation required when moving around the
 cube grid. The set of {\em \_EXCH} routines that contain the
