/[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.12 by afe,
Wed Jan 28 19:59:03 2004 UTC
+revision 1.19 by edhill,
Tue Apr 20 23:32:59 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
  of this process. These values are stored in global storage
  in the header file {\em EESUPPORT.h} for use by
- communication routines.
+ 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 the documentation on the exch2 package
+ (\ref{sec:exch2})  for
+ details.
  \\
  \fbox{
-Line 1090 
 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. The number is held in the variables {\em tileNo}
+ 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
  that specifies the type of communication that is used between tiles.
-Line 1116 
 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 package documentation
+ (\ref{sec:exch2} for details.
  \fbox{
  \begin{minipage}{4.75in}
-Line 1252 
 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 1269 
 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 1373 
 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
-Line 1397 
 quantities at the C-grid vorticity point
+Line 1421 
 quantities at the C-grid vorticity point
  \section{MITgcm execution under WRAPPER}
+ \begin{rawhtml}
+ <!-- CMIREDIR:mitgcm_wrapper: -->
+ \end{rawhtml}
  Fitting together the WRAPPER elements, package elements and
  MITgcm core equation elements of the source code produces calling

 Legend:



Removed from v.1.12
 


changed lines


 
Added in v.1.19
 Legend:



Removed from v.1.12
 


changed lines


 
Added in v.1.19
-Removed from v.1.12
+Added in v.1.19

	ViewVC Help
Powered by ViewVC 1.1.22