Changeset 817 for trunk/DOC/BETA/Chapters/Chap_LBC.tex

Timestamp:

2008-02-09T15:13:48+01:00 (16 years ago)

Author:

gm

Message:

trunk - update including Steven correction of the first 5 chapters (until DYN) and activation of Appendix A & B

File:

• trunk/DOC/BETA/Chapters/Chap_LBC.tex (modified) (3 diffs)

trunk/DOC/BETA/Chapters/Chap_LBC.tex

@@ -29 +29 @@
 }{e_{1u} }\delta _{i+1 / 2} \left[ T \right]\;\;mask_u 
 \end{equation}
-
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-\begin{figure}[!t] \label{Fig_LBC_uv}  \begin{center}
-\includegraphics[width=0.90\textwidth]{./Figures/Fig_LBC_uv.pdf}
-\caption {Lateral boundary (thick line) at T-level. The velocity normal to the boundary is set to zero.}
-\end{center}   \end{figure}
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-
 where mask$_{u}$ is the mask array at $u$-point, ensures that the heat flux is 
 zero inside land and at the boundaries as mask$_{u}$ is zero at solid 
 boundaries defined at $u$-points in this case (normal velocity $u$ remains zero at 
 the coast) (Fig.~\ref{Fig_LBC_uv}). 
+
+%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+\begin{figure}[!t] \label{Fig_LBC_uv}  \begin{center}
+\includegraphics[width=0.90\textwidth]{./Figures/Fig_LBC_uv.pdf}
+\caption {Lateral boundary (thick line) at T-level. The velocity normal to the boundary is set to zero.}
+\end{center}   \end{figure}
+%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
 On momentum the situation is a bit more complex as two boundary conditions must be provided along the coast (one on the normal velocity and the other on the tangential velocity). The boundary of the ocean in C-grid is defined by the velocity-faces. For example, at a given $T$-level, the lateral boundary (coastline or intersection with the bottom topography) is made of segments 
@@ -138 +137 @@
 
 % ====================================================================
-% Sub-Domain:Exchange with neighbouring processors 
+% Exchange with neighbouring processors 
 % ====================================================================
-\section{Exchange with neighbouring processors (\mdl{lbclnk}, \mdl{lib\_mpp})}
+\section  [Exchange with neighbouring processors (\textit{lbclnk}, \textit{lib\_mpp})]
+      {Exchange with neighbouring processors (\mdl{lbclnk}, \mdl{lib\_mpp})}
 \label{LBC_mpp}
 
@@ -185 +185 @@
 
 
-   The OPA model computes equation terms with the help of mask arrays (0 onto land points and 1 onto sea points). It is easily readable and very efficient in the context of the vectorial architecture. But in the case of scalar processor, computations over the land regions becomes more expensive in term of CPU time. It is all the more so when we use a complex configuration with a realistic bathymetry like the global ocean where more than 50 \% of points are land points. For this reason, a pre-processing tool allows to search in the mpp domain decomposition strategy if a splitting can be found with a maximum number of only land points processors which could be eliminated: the mpp\_optimiz tools (available from the DRAKKAR web site). This optimisation is made with the knowledge of the specific bathymetry. The user chooses optimal parameters \jp{jpni}, \jp{jpnj} and \jp{jpnij} with $jpnij < jpni \times jpnj$, leading to the elimination of $jpni \times jpnj - jpnij$ land processors. When those parameters are specified in module \mdl{par\_oce}, the algorithm in the \rou{inimpp2} routine set each processor name and neighbour parameters (nbound, nono, noea,...) so that the land processors are not taken into account. 
+   The OPA model computes equation terms with the help of mask arrays (0 onto land points and 1 onto sea points). It is easily readable and very efficient in the context of the vectorial architecture. Nevertheless, in the case of scalar processor, computations over the land regions becomes more expensive in term of CPU time. It is all the more so when we use a complex configuration with a realistic bathymetry like the global ocean where more than 50 \% of points are land points. For this reason, a pre-processing tool allows to search in the mpp domain decomposition strategy if a splitting can be found with a maximum number of only land points processors which could be eliminated: the mpp\_optimiz tools (available from the DRAKKAR web site). This optimisation is made with the knowledge of the specific bathymetry. The user chooses optimal parameters \jp{jpni}, \jp{jpnj} and \jp{jpnij} with $jpnij < jpni \times jpnj$, leading to the elimination of $jpni \times jpnj - jpnij$ land processors. When those parameters are specified in module \mdl{par\_oce}, the algorithm in the \rou{inimpp2} routine set each processor name and neighbour parameters (nbound, nono, noea,...) so that the land processors are not taken into account. 
 
 \colorbox{yellow}{Note that the inimpp2 routine is general so that the original inimpp routine should be suppressed from the code.}