Index: trunk/DOC/TexFiles/Chapters/Chap_LBC.tex
===================================================================
--- trunk/DOC/TexFiles/Chapters/Chap_LBC.tex	(revision 4528)
+++ trunk/DOC/TexFiles/Chapters/Chap_LBC.tex	(revision 6289)
@@ -1,4 +1,4 @@
 % ================================================================
-% Chapter � Lateral Boundary Condition (LBC) 
+% Chapter — Lateral Boundary Condition (LBC) 
 % ================================================================
 \chapter{Lateral Boundary Condition (LBC) }
@@ -127,22 +127,4 @@
 can be quite shallow.
 
-The alternative numerical implementation of the no-slip boundary conditions for an 
-arbitrary coast line of \citet{Shchepetkin1996} is also available through the 
-\key{noslip\_accurate} CPP key. It is based on a fourth order evaluation of the shear at the 
-coast which, in turn, allows a true second order scheme in the interior of the domain 
-($i.e.$ the numerical boundary scheme simulates the truncation error of the numerical 
-scheme used in the interior of the domain). \citet{Shchepetkin1996} found that such a 
-technique considerably improves the quality of the numerical solution. In \NEMO, such 
-spectacular improvements have not been found in the half-degree global ocean 
-(ORCA05), but significant reductions of numerically induced coastal upwellings were 
-found in an eddy resolving simulation of the Alboran Sea \citep{Olivier_PhD01}. 
-Nevertheless, since a no-slip boundary condition is not recommended in an eddy 
-permitting or resolving simulation \citep{Penduff_al_OS07}, the use of this option is also 
-not recommended.
-
-In practice, the no-slip accurate option changes the way the curl is evaluated at the 
-coast (see \mdl{divcur} module), and requires the nature of each coastline grid point 
-(convex or concave corners, straight north-south or east-west coast) to be specified.  
-This is performed in routine \rou{dom\_msk\_nsa} in the \mdl{domask} module.
 
 % ================================================================
@@ -204,10 +186,11 @@
 %        North fold (\textit{jperio = 3 }to $6)$ 
 % -------------------------------------------------------------------------------------------------------------
-\subsection{North-fold (\textit{jperio = 3 }to $6)$ }
+\subsection{North-fold (\textit{jperio = 3 }to $6$) }
 \label{LBC_north_fold}
 
 The north fold boundary condition has been introduced in order to handle the north 
-boundary of a three-polar ORCA grid. Such a grid has two poles in the northern hemisphere. 
-\colorbox{yellow}{to be completed...}
+boundary of a three-polar ORCA grid. Such a grid has two poles in the northern hemisphere 
+(Fig.\ref{Fig_MISC_ORCA_msh}, and thus requires a specific treatment illustrated in Fig.\ref{Fig_North_Fold_T}. 
+Further information can be found in \mdl{lbcnfd} module which applies the north fold boundary condition.
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -250,10 +233,9 @@
 ocean model. Second order finite difference schemes lead to local discrete 
 operators that depend at the very most on one neighbouring point. The only 
-non-local computations concern the vertical physics (implicit diffusion, 1.5 
+non-local computations concern the vertical physics (implicit diffusion, 
 turbulent closure scheme, ...) (delocalization over the whole water column), 
 and the solving of the elliptic equation associated with the surface pressure 
 gradient computation (delocalization over the whole horizontal domain). 
 Therefore, a pencil strategy is used for the data sub-structuration 
-\gmcomment{no idea what this means!}
 : the 3D initial domain is laid out on local processor 
 memories following a 2D horizontal topological splitting. Each sub-domain 
@@ -264,16 +246,14 @@
 phase starts: each processor sends to its neighbouring processors the update 
 values of the points corresponding to the interior overlapping area to its 
-neighbouring sub-domain (i.e. the innermost of the two overlapping rows). 
-The communication is done through message passing. Usually the parallel virtual 
-language, PVM, is used as it is a standard language available on  nearly  all 
-MPP computers. More specific languages (i.e. computer dependant languages) 
-can be easily used to speed up the communication, such as SHEM on a T3E 
-computer. The data exchanges between processors are required at the very 
+neighbouring sub-domain ($i.e.$ the innermost of the two overlapping rows). 
+The communication is done through the Message Passing Interface (MPI). 
+The data exchanges between processors are required at the very 
 place where lateral domain boundary conditions are set in the mono-domain 
-computation (\S III.10-c): the lbc\_lnk routine which manages such conditions 
-is substituted by mpplnk.F or mpplnk2.F routine when running on an MPP 
-computer (\key{mpp\_mpi} defined). It has to be pointed out that when using 
-the MPP version of the model, the east-west cyclic boundary condition is done 
-implicitly, whilst the south-symmetric boundary condition option is not available.
+computation : the \rou{lbc\_lnk} routine (found in \mdl{lbclnk} module) 
+which manages such conditions is interfaced with routines found in \mdl{lib\_mpp} module 
+when running on an MPP computer ($i.e.$ when \key{mpp\_mpi} defined). 
+It has to be pointed out that when using the MPP version of the model, 
+the east-west cyclic boundary condition is done implicitly, 
+whilst the south-symmetric boundary condition option is not available.
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -285,12 +265,10 @@
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
-In the standard version of the OPA model, the splitting is regular and arithmetic.
- the i-axis is divided by \jp{jpni} and the j-axis by \jp{jpnj} for a number of processors 
- \jp{jpnij} most often equal to $jpni \times jpnj$ (model parameters set in 
- \mdl{par\_oce}). Each processor is independent and without message passing 
- or synchronous process 
- \gmcomment{how does a synchronous process relate to this?}, 
- programs run alone and access just its own local memory. For this reason, the 
- main model dimensions are now the local dimensions of the subdomain (pencil) 
+In the standard version of \NEMO, the splitting is regular and arithmetic.
+The i-axis is divided by \jp{jpni} and the j-axis by \jp{jpnj} for a number of processors 
+\jp{jpnij} most often equal to $jpni \times jpnj$ (parameters set in 
+ \ngn{nammpp} namelist). Each processor is independent and without message passing 
+ or synchronous process, programs run alone and access just its own local memory. 
+ For this reason, the main model dimensions are now the local dimensions of the subdomain (pencil) 
  that are named \jp{jpi}, \jp{jpj}, \jp{jpk}. These dimensions include the internal 
  domain and the overlapping rows. The number of rows to exchange (known as 
@@ -304,12 +282,8 @@
 where \jp{jpni}, \jp{jpnj} are the number of processors following the i- and j-axis.
 
-\colorbox{yellow}{Figure IV.3: example of a domain splitting with 9 processors and 
-no east-west cyclic boundary conditions.}
-
-One also defines variables nldi and nlei which correspond to the internal 
-domain bounds, and the variables nimpp and njmpp which are the position 
-of the (1,1) grid-point in the global domain. An element of $T_{l}$, a local array 
-(subdomain) corresponds to an element of $T_{g}$, a global array 
-(whole domain) by the relationship: 
+One also defines variables nldi and nlei which correspond to the internal domain bounds, 
+and the variables nimpp and njmpp which are the position of the (1,1) grid-point in the global domain. 
+An element of $T_{l}$, a local array (subdomain) corresponds to an element of $T_{g}$, 
+a global array (whole domain) by the relationship: 
 \begin{equation} \label{Eq_lbc_nimpp}
 T_{g} (i+nimpp-1,j+njmpp-1,k) = T_{l} (i,j,k),
@@ -320,6 +294,5 @@
 nproc. In the standard version, a processor has no more than four neighbouring 
 processors named nono (for north), noea (east), noso (south) and nowe (west) 
-and two variables, nbondi and nbondj, indicate the relative position of the processor 
-\colorbox{yellow}{(see Fig.IV.3)}:
+and two variables, nbondi and nbondj, indicate the relative position of the processor :
 \begin{itemize}
 \item 		nbondi = -1 	an east neighbour, no west processor,
@@ -332,6 +305,4 @@
 processor on its overlapping row, and sends the data issued from internal 
 domain corresponding to the overlapping row of the other processor.
-		 
-\colorbox{yellow}{Figure IV.4: pencil splitting with the additional outer halos }
 
 
@@ -343,27 +314,20 @@
 global ocean where more than 50 \% of points are land points. For this reason, a 
 pre-processing tool can be used to choose the mpp domain decomposition with a 
-maximum number of only land points processors, which can then be eliminated. 
-(For example, the mpp\_optimiz tools, available from the DRAKKAR web site.) 
+maximum number of only land points processors, which can then be eliminated (Fig. \ref{Fig_mppini2})
+(For example, the mpp\_optimiz tools, available from the DRAKKAR web site). 
 This optimisation is dependent on the specific bathymetry employed. The user 
 then 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}, 
+land processors. When those parameters are specified in \ngn{nammpp} namelist, 
 the algorithm in the \rou{inimpp2} routine sets each processor's parameters (nbound, 
 nono, noea,...) so that the land-only processors are not taken into account. 
 
-\colorbox{yellow}{Note that the inimpp2 routine is general so that the original inimpp 
+\gmcomment{Note that the inimpp2 routine is general so that the original inimpp 
 routine should be suppressed from the code.}
 
 When land processors are eliminated, the value corresponding to these locations in 
-the model output files is zero. Note that this is a problem for a mesh output file written 
-by such a model configuration, because model users often divide by the scale factors 
-($e1t$, $e2t$, etc) and do not expect the grid size to be zero, even on land. It may be 
-best not to eliminate land processors when running the model especially to write the 
-mesh files as outputs (when \np{nn\_msh} namelist parameter differs from 0).
-%%
-\gmcomment{Steven : dont understand this, no land processor means no output file 
-covering this part of globe; its only when files are stitched together into one that you 
-can leave a hole}
-%%
+the model output files is undefined. Note that this is a problem for the meshmask file 
+which requires to be defined over the whole domain. Therefore, user should not eliminate 
+land processors when creating a meshmask file ($i.e.$ when setting a non-zero value to \np{nn\_msh}).
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -380,360 +344,4 @@
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
-
-% ================================================================
-% Open Boundary Conditions 
-% ================================================================
-\section{Open Boundary Conditions (\key{obc}) (OBC)}
-\label{LBC_obc}
-%-----------------------------------------nam_obc  -------------------------------------------
-%-    nobc_dta    =    0     !  = 0 the obc data are equal to the initial state
-%-                           !  = 1 the obc data are read in 'obc   .dta' files
-%-    rn_dpein      =    1.    !  ???
-%-    rn_dpwin      =    1.    !  ???
-%-    rn_dpnin      =   30.    !  ???
-%-    rn_dpsin      =    1.    !  ???
-%-    rn_dpeob      = 1500.    !  time relaxation (days) for the east  open boundary
-%-    rn_dpwob      =   15.    !    "        "           for the west  open boundary
-%-    rn_dpnob      =  150.    !    "        "           for the north open boundary
-%-    rn_dpsob      =   15.    !    "        "           for the south open boundary
-%-    ln_obc_clim = .true.   !  climatological obc data files (default T)
-%-    ln_vol_cst  = .true.   !  total volume conserved
-\namdisplay{namobc} 
-
-It is often necessary to implement a model configuration limited to an oceanic 
-region or a basin, which communicates with the rest of the global ocean through 
-''open boundaries''. As stated by \citet{Roed1986}, an open boundary is a 
-computational border where the aim of the calculations is to allow the perturbations 
-generated inside the computational domain to leave it without deterioration of the 
-inner model solution. However, an open boundary also has to let information from 
-the outer ocean enter the model and should support inflow and outflow conditions. 
-
-The open boundary package OBC is the first open boundary option developed in 
-NEMO (originally in OPA8.2). It allows the user to 
-\begin{itemize}
-\item tell the model that a boundary is ''open'' and not closed by a wall, for example 
-by modifying the calculation of the divergence of velocity there;
-\item impose values of tracers and velocities at that boundary (values which may 
-be taken from a climatology): this is the``fixed OBC'' option. 
-\item calculate boundary values by a sophisticated algorithm combining radiation 
-and relaxation (``radiative OBC'' option)
-\end{itemize}
-
-Options are defined through the \ngn{namobc} namelist variables.
-The package resides in the OBC directory. It is described here in four parts: the 
-boundary geometry (parameters to be set in \mdl{obc\_par}), the forcing data at 
-the boundaries (module \mdl{obcdta}),  the radiation algorithm involving the 
-namelist and module \mdl{obcrad}, and a brief presentation of boundary update 
-and restart files.
-
-%----------------------------------------------
-\subsection{Boundary geometry}
-\label{OBC_geom}
-%
-First one has to realize that open boundaries may not necessarily be located 
-at the extremities of the computational domain. They may exist in the middle 
-of the domain, for example at Gibraltar Straits if one wants to avoid including 
-the Mediterranean in an Atlantic domain. This flexibility has been found necessary 
-for the CLIPPER project \citep{Treguier_al_JGR01}. Because of the complexity of the 
-geometry of ocean basins, it may even be necessary to have more than one 
-''west'' open boundary, more than one ''north'', etc. This is not possible with 
-the OBC option: only one open boundary of each kind, west, east, south and 
-north is allowed; these names refer to the grid geometry (not to the direction 
-of the geographical ''west'', ''east'', etc).
-
-The open boundary geometry is set by a series of parameters in the module 
-\mdl{obc\_par}. For an eastern open boundary, parameters are \jp{lp\_obc\_east} 
-(true if an east open boundary exists), \jp{jpieob} the $i$-index along which 
-the eastern open boundary (eob) is located, \jp{jpjed} the $j$-index at which 
-it starts, and \jp{jpjef} the $j$-index where it ends (note $d$ is for ''d\'{e}but'' 
-and $f$ for ''fin'' in French). Similar parameters exist for the west, south and 
-north cases (Table~\ref{Tab_obc_param}).
-
-
-%--------------------------------------------------TABLE--------------------------------------------------
-\begin{table}[htbp]     \begin{center}    \begin{tabular}{|l|c|c|c|}
-\hline
-Boundary and  & Constant index  & Starting index (d\'{e}but) & Ending index (fin) \\
-Logical flag  &                 &                            &                     \\
-\hline
-West          & \jp{jpiwob} $>= 2$         &  \jp{jpjwd}$>= 2$          &  \jp{jpjwf}<= \np{jpjglo}-1 \\
-lp\_obc\_west & $i$-index of a $u$ point   & $j$ of a $T$ point   &$j$ of a $T$ point \\
-\hline
-East            & \jp{jpieob}$<=$\np{jpiglo}-2&\jp{jpjed} $>= 2$         & \jp{jpjef}$<=$ \np{jpjglo}-1 \\
- lp\_obc\_east  & $i$-index of a $u$ point    & $j$ of a $T$ point & $j$ of a $T$ point \\
-\hline
-South           & \jp{jpjsob} $>= 2$         & \jp{jpisd} $>= 2$          & \jp{jpisf}$<=$\np{jpiglo}-1 \\
-lp\_obc\_south  & $j$-index of a $v$ point   & $i$ of a $T$ point   & $i$ of a $T$ point \\
-\hline
-North           & \jp{jpjnob} $<=$ \np{jpjglo}-2& \jp{jpind} $>= 2$        & \jp{jpinf}$<=$\np{jpiglo}-1 \\
-lp\_obc\_north  & $j$-index of a $v$ point      & $i$  of a $T$ point & $i$ of a $T$ point \\
-\hline
-\end{tabular}    \end{center}
-\caption{     \label{Tab_obc_param}
-Names of different indices relating to the open boundaries. In the case 
-of a completely open ocean domain with four ocean boundaries, the parameters 
-take exactly the values indicated.}
-\end{table}
-%------------------------------------------------------------------------------------------------------------
-
-The open boundaries must be along coordinate lines. On the C-grid, the boundary 
-itself is along a line of normal velocity points: $v$ points for a zonal open boundary 
-(the south or north one), and $u$ points for a meridional open boundary (the west 
-or east one). Another constraint is that there still must be a row of masked points 
-all around the domain, as if the domain were a closed basin (unless periodic conditions 
-are used together with open boundary conditions). Therefore, an open boundary 
-cannot be located at the first/last index, namely, 1, \jp{jpiglo} or \jp{jpjglo}. Also, 
-the open boundary algorithm involves calculating the normal velocity points situated 
-just on the boundary, as well as the tangential velocity and temperature and salinity 
-just outside the boundary. This means that for a west/south boundary, normal 
-velocities and temperature are calculated at the same index \jp{jpiwob} and 
-\jp{jpjsob}, respectively. For an east/north boundary, the normal velocity is 
-calculated at index \jp{jpieob} and \jp{jpjnob}, but the ``outside'' temperature is 
-at index \jp{jpieob}+1 and \jp{jpjnob}+1. This means that \jp{jpieob}, \jp{jpjnob} 
-cannot be bigger than \jp{jpiglo}-2, \jp{jpjglo}-2. 
-
-
-The starting and ending indices are to be thought of as $T$ point indices: in many 
-cases they indicate the first land $T$-point, at the extremity of an open boundary 
-(the coast line follows the $f$ grid points, see Fig.~\ref{Fig_obc_north} for an example 
-of a northern open boundary). All indices are relative to the global domain. In the 
-free surface case it is possible to have ``ocean corners'', that is, an open boundary 
-starting and ending in the ocean.
-
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-\begin{figure}[!t]     \begin{center}
-\includegraphics[width=0.70\textwidth]{./TexFiles/Figures/Fig_obc_north.pdf}
-\caption{    \label{Fig_obc_north}
-Localization of the North open boundary points.}
-\end{center}     \end{figure}
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-
-Although not compulsory, it is highly recommended that the bathymetry in the 
-vicinity of an open boundary follows the following rule: in the direction perpendicular 
-to the open line, the water depth should be constant for 4 grid points. This is in 
-order to ensure that the radiation condition, which involves model variables next 
-to the boundary, is calculated in a consistent way. On Fig.\ref{Fig_obc_north} we 
-indicate by an $=$ symbol, the points which should have the same depth. It means 
-that at the 4 points near the boundary, the bathymetry is cylindrical \gmcomment{not sure 
-why cylindrical}. The line behind the open $T$-line must be 0 in the bathymetry file 
-(as shown on Fig.\ref{Fig_obc_north} for example).
-
-%----------------------------------------------
-\subsection{Boundary data}
-\label{OBC_data}
-
-It is necessary to provide information at the boundaries. The simplest case is 
-when this information does not change in time and is equal to the initial conditions 
-(namelist variable \np{nn\_obcdta}=0). This is the case for the standard configuration 
-EEL5 with open boundaries. When (\np{nn\_obcdta}=1), open boundary information 
-is read from netcdf files. For convenience the input files are supposed to be similar 
-to the ''history'' NEMO output files, for dimension names and variable names. 
-Open boundary arrays must be dimensioned according to the parameters of table~
-\ref{Tab_obc_param}: for example, at the western boundary, arrays have a 
-dimension of \jp{jpwf}-\jp{jpwd}+1 in the horizontal and \jp{jpk} in the vertical. 
-
-When ocean observations are used to generate the boundary data (a hydrographic 
-section for example, as in \citet{Treguier_al_JGR01}) it happens often that only the velocity 
-normal to the boundary is known, which is the reason why the initial OBC code 
-assumes that only $T$, $S$, and the normal velocity ($u$ or $v$) needs to be 
-specified. As more and more global model solutions and ocean analysis products 
-become available, it will be possible to provide information about all the variables 
-(including the tangential velocity) so that the specification of four variables at each 
-boundaries will become standard. For the sea surface height, one must distinguish 
-between the filtered free surface case and the time-splitting or explicit treatment of 
-the free surface.
- In the first case, it is assumed that the user does not wish to represent high 
- frequency motions such as tides. The boundary condition is thus one of zero 
- normal gradient of sea surface height at the open boundaries, following \citet{Marchesiello2001}. 
-No information other than the total velocity needs to be provided at the open 
-boundaries in that case. In the other two cases (time splitting or explicit free surface), 
-the user must provide barotropic information (sea surface height and barotropic 
-velocities) and the use of the Flather algorithm for barotropic variables is 
-recommanded. However, this algorithm has not yet been fully tested and bugs 
-remain in NEMO v2.3. Users should read the code carefully before using it. Finally, 
-in the case of the rigid lid approximation the barotropic streamfunction must be 
-provided, as documented in \citet{Treguier_al_JGR01}). This option is no longer 
-recommended but remains in NEMO V2.3.
-
-One frequently encountered case is when an open boundary domain is constructed 
-from a global or larger scale NEMO configuration. Assuming the domain corresponds 
-to indices $ib:ie$, $jb:je$ of the global domain, the bathymetry and forcing of the 
-small domain can be created by using the following netcdf utility on the global files: 
-ncks -F $-d\;x,ib,ie$ $-d\;y,jb,je$ (part of the nco series of utilities, 
-see their \href{http://nco.sourceforge.net}{website}). 
-The open boundary files can be constructed using ncks 
-commands, following table~\ref{Tab_obc_ind}. 
-
-%--------------------------------------------------TABLE--------------------------------------------------
-\begin{table}[htbp]     \begin{center}      \begin{tabular}{|l|c|c|c|c|c|}
-\hline
-OBC  & Variable   & file name      & Index  & Start  & end  \\
-West &  T,S       &   obcwest\_TS.nc &  $ib$+1     &   $jb$+1 &  $je-1$  \\
-     &    U       &   obcwest\_U.nc  &  $ib$+1     &   $jb$+1 &  $je-1$  \\ 
-     &    V       &   obcwest\_V.nc  &  $ib$+1     &   $jb$+1 &  $je-1$  \\       
-\hline
-East &  T,S       &   obceast\_TS.nc &  $ie$-1     &   $jb$+1 &  $je-1$  \\
-     &    U       &   obceast\_U.nc  &  $ie$-2     &   $jb$+1 &  $je-1$  \\ 
-     &    V       &   obceast\_V.nc  &  $ie$-1     &   $jb$+1 &  $je-1$  \\       
-\hline         
-South &  T,S      &   obcsouth\_TS.nc &  $jb$+1     &  $ib$+1 &  $ie-1$  \\
-      &    U      &   obcsouth\_U.nc  &  $jb$+1     &  $ib$+1 &  $ie-1$  \\ 
-      &    V      &   obcsouth\_V.nc  &  $jb$+1     &  $ib$+1 &  $ie-1$  \\    
-\hline
-North &  T,S      &   obcnorth\_TS.nc &  $je$-1     &  $ib$+1 &  $ie-1$  \\
-      &    U      &   obcnorth\_U.nc  &  $je$-1     &  $ib$+1 &  $ie-1$  \\ 
-      &    V      &   obcnorth\_V.nc  &  $je$-2     &  $ib$+1 &  $ie-1$  \\  
-\hline
-\end{tabular}     \end{center}
-\caption{    \label{Tab_obc_ind}
-Requirements for creating open boundary files from a global configuration, 
-appropriate for the subdomain of indices $ib:ie$, $jb:je$. ``Index'' designates the 
-$i$ or $j$ index along which the $u$ of $v$ boundary point is situated in the global 
-configuration, starting and ending with the $j$ or $i$ indices indicated. 
-For example, to generate file obcnorth\_V.nc, use the command ncks 
-$-F$ $-d\;y,je-2$  $-d\;x,ib+1,ie-1$ } 
-\end{table}
-%-----------------------------------------------------------------------------------------------------------
-
-It is assumed that the open boundary files contain the variables for the period of 
-the model integration. If the boundary files contain one time frame, the boundary 
-data is held fixed in time. If the files contain 12 values, it is assumed that the input 
-is a climatology for a repeated annual cycle (corresponding to the case \np{ln\_obc\_clim} 
-=true). The case of an arbitrary number of time frames is not yet implemented 
-correctly; the user is required to write his own code in the module \mdl{obc\_dta} 
-to deal with this situation. 
-
-\subsection{Radiation algorithm}
-\label{OBC_rad}
-
-The art of open boundary management consists in applying a constraint strong 
-enough that the inner domain "feels" the rest of the ocean, but weak enough
-that perturbations are allowed to leave the domain with minimum false reflections 
-of energy. The constraints are specified separately at each boundary as time 
-scales for ''inflow'' and ''outflow'' as defined below. The time scales are set (in days) 
-by namelist parameters such as \np{rn\_dpein}, \np{rn\_dpeob} for the eastern open 
-boundary for example. When both time scales are zero for a given boundary 
-($e.g.$ for the western boundary, \jp{lp\_obc\_west}=true, \np{rn\_dpwob}=0 and 
-\np{rn\_dpwin}=0) this means that the boundary in question is a ''fixed '' boundary 
-where the solution is set exactly by the boundary data. This is not recommended, 
-except in combination with increased viscosity in a ''sponge'' layer next to the 
-boundary in order to avoid spurious reflections.  
-
-
-The radiation\/relaxation \gmcomment{the / doesnt seem to appear in the output} 
-algorithm is applied when either relaxation time (for ''inflow'' or ''outflow'') is 
-non-zero. It has been developed and tested in the SPEM model and its 
-successor ROMS \citep{Barnier1996, Marchesiello2001}, which is an 
-$s$-coordinate model on an Arakawa C-grid. Although the algorithm has 
-been numerically successful in the CLIPPER Atlantic models, the physics 
-do not work as expected \citep{Treguier_al_JGR01}. Users are invited to consider 
-open boundary conditions (OBC hereafter) with some scepticism 
-\citep{Durran2001, Blayo2005}.
-
-The first part of the algorithm calculates a phase velocity to determine 
-whether perturbations tend to propagate toward, or away from, the 
-boundary. Let us consider a model variable $\phi$. 
-The phase velocities ($C_{\phi x}$,$C_{\phi y}$) for the variable $\phi$, 
-in the directions normal and tangential to the boundary are
-\begin{equation} \label{Eq_obc_cphi}
-C_{\phi x} = \frac{ -\phi_{t} }{ ( \phi_{x}^{2} + \phi_{y}^{2}) } \phi_{x} 
-\;\;\;\;\; \;\;\; 
-C_{\phi y} = \frac{ -\phi_{t} }{ ( \phi_{x}^{2} + \phi_{y}^{2}) } \phi_{y}. 
-\end{equation}
-Following \citet{Treguier_al_JGR01} and \citet{Marchesiello2001} we retain only 
-the normal component of the velocity, $C_{\phi x}$, setting $C_{\phi y} =0$ 
-(but unlike the original Orlanski radiation algorithm we retain $\phi_{y}$ in 
-the expression for $C_{\phi x}$).  
-
-The discrete form of (\ref{Eq_obc_cphi}), described by \citet{Barnier1998},
-takes into account the two rows of grid points situated inside the domain 
-next to the boundary, and the three previous time steps ($n$, $n-1$,
-and $n-2$). The same equation can then be discretized at the boundary at
-time steps $n-1$, $n$ and $n+1$ \gmcomment{since the original was three time-level} 
-in order to extrapolate for the new boundary value $\phi^{n+1}$. 
-
-In the open boundary algorithm as implemented in NEMO v2.3, the new boundary 
-values are updated differently depending on the sign of $C_{\phi x}$. Let us take 
-an eastern boundary as an example. The solution for variable $\phi$ at the 
-boundary is given by a generalized wave equation with phase velocity $C_{\phi}$, 
-with the addition of a relaxation term, as:
-\begin{eqnarray}
-\phi_{t} &  =  & -C_{\phi x} \phi_{x} + \frac{1}{\tau_{o}} (\phi_{c}-\phi) 
-                        \;\;\; \;\;\; \;\;\; (C_{\phi x} > 0), \label{Eq_obc_rado} \\
-\phi_{t} &  =  & \frac{1}{\tau_{i}} (\phi_{c}-\phi) 
-\;\;\; \;\;\; \;\;\;\;\;\; (C_{\phi x} < 0), \label{Eq_obc_radi}
-\end{eqnarray}
-where $\phi_{c}$ is the estimate of $\phi$ at the boundary, provided as boundary 
-data. Note that in (\ref{Eq_obc_rado}), $C_{\phi x}$ is bounded by the ratio 
-$\delta x/\delta t$ for stability reasons. When $C_{\phi x}$ is eastward (outward 
-propagation), the radiation condition (\ref{Eq_obc_rado}) is used. 
-When  $C_{\phi x}$ is westward (inward propagation), (\ref{Eq_obc_radi}) is 
-used with a strong relaxation to climatology (usually $\tau_{i}=\np{rn\_dpein}=$1~day).
-Equation (\ref{Eq_obc_radi}) is solved with a Euler time-stepping scheme. As a 
-consequence, setting $\tau_{i}$ smaller than, or equal to the time step is equivalent 
-to a fixed boundary condition. A time scale of one day is usually a good compromise 
-which guarantees that the inflow conditions remain close to climatology while ensuring 
-numerical stability. 
-
-In  the case of a western boundary located in the Eastern Atlantic, \citet{Penduff_al_JGR00} 
-have been able to implement the radiation algorithm without any boundary data, 
-using persistence from the previous time step instead. This solution has not worked 
-in other cases \citep{Treguier_al_JGR01}, so that the use of boundary data is recommended. 
-Even in the outflow condition (\ref{Eq_obc_rado}), we have found it desirable to 
-maintain a weak relaxation to climatology. The time step is usually chosen so as to 
-be larger than typical turbulent scales (of order 1000~days \gmcomment{or maybe seconds?}).
-
-The radiation condition is applied to the model variables: temperature, salinity, 
-tangential and normal velocities. For normal and tangential velocities, $u$ and $v$, 
-radiation is applied with phase velocities calculated from $u$ and $v$ respectively.  
-For the radiation of tracers, we use the phase velocity calculated from the tangential 
-velocity in order to avoid calculating too many independent radiation velocities and 
-because tangential velocities and tracers have the same position along the boundary 
-on a C-grid.  
-
-\subsection{Domain decomposition (\key{mpp\_mpi})}
-\label{OBC_mpp}
-When \key{mpp\_mpi} is active in the code, the computational domain is divided 
-into rectangles that are attributed each to a different processor. The open boundary 
-code is ``mpp-compatible'' up to a certain point. The radiation algorithm will not 
-work if there is an mpp subdomain boundary parallel to the open boundary at the 
-index of the boundary, or the grid point after (outside), or three grid points before 
-(inside). On the other hand, there is no problem if an mpp subdomain boundary 
-cuts the open boundary perpendicularly. These geometrical limitations must be 
-checked for by the user (there is no safeguard in the code).  
-The general principle for the open boundary mpp code is that loops over the open 
-boundaries {not sure what this means} are performed on local indices (nie0, 
-nie1, nje0, nje1 for an eastern boundary for instance) that are initialized in module 
-\mdl{obc\_ini}. Those indices have relevant values on the processors that contain 
-a segment of an open boundary. For processors that do not include an open 
-boundary segment, the indices are such that the calculations within the loops are 
-not performed.
-\gmcomment{I dont understand most of the last few sentences}
- 
-Arrays of climatological data that are read from files are seen by all processors 
-and have the same dimensions for all (for instance, for the eastern boundary, 
-uedta(jpjglo,jpk,2)). On the other hand, the arrays for the calculation of radiation 
-are local to each processor (uebnd(jpj,jpk,3,3) for instance).  This allowed the 
-CLIPPER model for example, to save on memory where the eastern boundary 
-crossed 8 processors so that \jp{jpj} was much smaller than (\jp{jpjef}-\jp{jpjed}+1). 
-
-\subsection{Volume conservation}
-\label{OBC_vol}
-
-It is necessary to control the volume inside a domain when using open boundaries. 
-With fixed boundaries, it is enough to ensure that the total inflow/outflow has 
-reasonable values (either zero or a value compatible with an observed volume 
-balance). When using radiative boundary conditions it is necessary to have a 
-volume constraint because each open boundary works independently from the 
-others. The methodology used to control this volume is identical to the one 
-coded in the ROMS model \citep{Marchesiello2001}.
-
-
-%---------------------------------------- EXTRAS
-\colorbox{yellow}{Explain obc\_vol{\ldots}}
-
-\colorbox{yellow}{OBC algorithm for update, OBC restart, list of routines where obc key appears{\ldots}}
-
-\colorbox{yellow}{OBC rigid lid? {\ldots}}
 
 % ====================================================================
