/[MITgcm]/manual/s_software/text/sarch.tex

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

Parent Directory | Revision Log | View Revision Graph Revision Graph | View Patch Patch

-revision 1.14 by afe,
Wed Jan 28 20:38:28 2004 UTC
+revision 1.17 by afe,
Tue Mar 23 15:29:40 2004 UTC
 Line 76 
 floating point operations.}
  \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
-Line 150 
 easily be specialized to fit, in a compu
+Line 153 
 easily be specialized to fit, in a compu
  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.
-Line 977 
 program, MPI is used. The calls to the M
+Line 983 
 program, MPI is used. The calls to the M
  routines must be activated at compile time.  Currently MPI libraries are
  invoked by
  specifying the appropriate options file with the
- \begin{verbatim}-of\end{verbatim} flag when running the {\em genmake2}
+ {\tt-of} flag when running the {\em genmake2}
  script, which generates the Makefile for compiling and linking MITgcm.
  (Previously this was done by setting the {\em ALLOW\_USE\_MPI} and
  {\em ALWAYS\_USE\_MPI} flags in the {\em CPP\_EEOPTIONS.h} file.)  More
  detailed information about the use of {\em genmake2} for specifying
- local compiler flags is located in section 3 ??\\
+ local compiler flags is located in section \ref{sect:genmake}.\\
  \fbox{
  \begin{minipage}{4.75in}
+ Directory: {\em tools/build\_options}\\
  File: {\em tools/genmake2}
  \end{minipage}
  } \\
-Line 1005 
 product of the processor grid settings o
+Line 1012 
 product of the processor grid settings o
  in the file {\em SIZE.h}. The parameter {\em mf} specifies that a text file
  called ``mf'' will be read to get a list of processor names on
  which the sixty-four processes will execute. The syntax of this file
- is specified by the MPI distribution
+ is specified by the MPI distribution.
  \\
  \fbox{
-Line 1056 
 to processor identification are are used
+Line 1063 
 to processor identification are are used
  Allocation of processes to tiles in controlled by the routine
  {\em INI\_PROCS()}. For each process this routine sets
  the variables {\em myXGlobalLo} and {\em myYGlobalLo}.
- These variables specify (in index space) the coordinate
+ These variables specify in index space the coordinates
- of the southern most and western most corner of the
+ of the southernmost and westernmost corner of the
- southern most and western most tile owned by this process.
+ southernmost and westernmost tile owned by this process.
  The variables {\em pidW}, {\em pidE}, {\em pidS} and {\em pidN}
  are also set in this routine. These are used to identify
  processes holding tiles to the west, east, south and north
-Line 1067 
 in the header file {\em EESUPPORT.h} for
+Line 1074 
 in the header file {\em EESUPPORT.h} for
  communication routines.  The above does not hold when the
  exch2 package is used -- exch2 sets its own parameters to
  specify the global indices of tiles and their relationships
- to each other.  See exch2 docs for details??.
+ to each other.  See the documentation on the exch2 package
+ (\ref{sec:exch2})  for
+ details.
  \\
  \fbox{
-Line 1093 
 operations and that can be customized fo
+Line 1102 
 operations and that can be customized fo
  describes the information that is held and used.
  \begin{enumerate}
- \item {\bf Tile-tile connectivity information} For each tile the WRAPPER
+ \item {\bf Tile-tile connectivity information}
- sets a flag that sets the tile number to the north, south, east and
+ For each tile the WRAPPER
+ sets a flag that sets the tile number to the north,
+ south, east and
  west of that tile. This number is unique over all tiles in a
- configuration. Except when using the exch2 package,
+ configuration. Except when using the cubed sphere and the exch2 package,
  the number is held in the variables {\em tileNo}
  ( this holds the tiles own number), {\em tileNoN}, {\em tileNoS},
  {\em tileNoE} and {\em tileNoW}. A parameter is also stored with each tile
-Line 1120 
 of the WRAPPER exchange primitive
+Line 1131 
 of the WRAPPER exchange primitive
  (see figure \ref{fig:communication_primitives}). The routine
  {\em ini\_communication\_patterns()} is responsible for setting the
  communication mode values for each tile.
- \\
  When using the cubed sphere configuration with the exch2 package, the
  relationships between tiles and their communication methods are set
- by the package in other variables.  See the exch2 docs for details.??
+ by the package in other variables.  See the exch2 package documentation
+ (\ref{sec:exch2} for details.
-Line 1262 
 The \_EXCH operation is also central to
+Line 1273 
 The \_EXCH operation is also central to
  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
-Line 1279 
 operations. However, the routine argumen
+Line 1292 
 operations. However, the routine argumen
  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
-Line 1383 
 a series of template files, for example
+Line 1397 
 a series of template files, for example
  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

 Legend:



Removed from v.1.14
 


changed lines


 
Added in v.1.17
 Legend:



Removed from v.1.14
 


changed lines


 
Added in v.1.17
-Removed from v.1.14
+Added in v.1.17

	ViewVC Help
Powered by ViewVC 1.1.22