Index: NEMO/trunk/doc/latex/NEMO/subfiles/chap_OBS.tex
===================================================================
--- NEMO/trunk/doc/latex/NEMO/subfiles/chap_OBS.tex	(revision 10146)
+++ NEMO/trunk/doc/latex/NEMO/subfiles/chap_OBS.tex	(revision 10354)
@@ -15,39 +15,39 @@
 $\ $\newline    % force a new line
 
-The observation and model comparison code (OBS) reads in observation files (profile
-temperature and salinity, sea surface temperature, sea level anomaly, sea ice concentration,
-and velocity) and calculates  an interpolated model equivalent value at the observation
-location and nearest model timestep. The resulting data are saved in a ``feedback'' file (or
-files). The code was originally developed for use with the NEMOVAR data assimilation code, but
-can be used for validation or verification of the model or with any other data assimilation system.
-
-The OBS code is called from \mdl{nemogcm} for model initialisation and to calculate the model
-equivalent values for observations on the 0th timestep. The code is then called again after
-each timestep from \mdl{step}. The code is only activated if the namelist logical \np{ln\_diaobs}
-is set to true.
-
-For all data types a 2D horizontal interpolator or averager is needed to interpolate/average the model fields to
-the observation location. For {\em in situ} profiles, a 1D vertical interpolator is needed in
-addition to provide model fields at the observation depths. This now works in a generalised vertical
-coordinate system. 
+The observation and model comparison code (OBS) reads in observation files
+(profile temperature and salinity, sea surface temperature, sea level anomaly, sea ice concentration, and velocity) and calculates an interpolated model equivalent value at the observation location and nearest model timestep.
+The resulting data are saved in a ``feedback'' file (or files).
+The code was originally developed for use with the NEMOVAR data assimilation code,
+but can be used for validation or verification of the model or with any other data assimilation system.
+
+The OBS code is called from \mdl{nemogcm} for model initialisation and to calculate the model equivalent values for observations on the 0th timestep.
+The code is then called again after each timestep from \mdl{step}.
+The code is only activated if the namelist logical \np{ln\_diaobs} is set to true.
+
+For all data types a 2D horizontal interpolator or averager is needed to
+interpolate/average the model fields to the observation location.
+For {\em in situ} profiles, a 1D vertical interpolator is needed in addition to
+provide model fields at the observation depths.
+This now works in a generalised vertical coordinate system. 
 
 Some profile observation types (e.g. tropical moored buoys) are made available as daily averaged quantities.
-The observation operator code can be set-up to calculate the equivalent daily average model temperature fields
-using the \np{nn\_profdavtypes} namelist array. Some SST observations are equivalent to a night-time
-average value and the observation operator code can calculate equivalent night-time average model SST fields by
-setting the namelist value \np{ln\_sstnight} to true. Otherwise the model value from the nearest timestep to the
-observation time is used.
-
-The code is controlled by the namelist \textit{namobs}. See the following sections for more
-details on setting up the namelist.
+The observation operator code can be set-up to calculate the equivalent daily average model temperature fields using
+the \np{nn\_profdavtypes} namelist array.
+Some SST observations are equivalent to a night-time average value and
+the observation operator code can calculate equivalent night-time average model SST fields by
+setting the namelist value \np{ln\_sstnight} to true.
+Otherwise the model value from the nearest timestep to the observation time is used.
+
+The code is controlled by the namelist \textit{namobs}.
+See the following sections for more details on setting up the namelist.
 
 \autoref{sec:OBS_example} introduces a test example of the observation operator code including
-where to obtain data and how to setup the namelist. \autoref{sec:OBS_details} introduces some
-more technical details of the different observation types used and also shows a more complete
-namelist. \autoref{sec:OBS_theory} introduces some of the theoretical aspects of the observation
-operator including interpolation methods and running on multiple processors.
+where to obtain data and how to setup the namelist.
+\autoref{sec:OBS_details} introduces some more technical details of the different observation types used and
+also shows a more complete namelist.
+\autoref{sec:OBS_theory} introduces some of the theoretical aspects of the observation operator including
+interpolation methods and running on multiple processors.
 \autoref{sec:OBS_ooo} describes the offline observation operator code.
-\autoref{sec:OBS_obsutils} introduces some utilities to help working with the files
-produced by the OBS code.
+\autoref{sec:OBS_obsutils} introduces some utilities to help working with the files produced by the OBS code.
 
 % ================================================================
@@ -58,14 +58,13 @@
 
 This section describes an example of running the observation operator code using
-profile data which can be freely downloaded. It shows how to adapt an
-existing run and build of NEMO to run the observation operator.
+profile data which can be freely downloaded.
+It shows how to adapt an existing run and build of NEMO to run the observation operator.
 
 \begin{enumerate}
 \item Compile NEMO.
 
-\item Download some EN4 data from 
-\href{http://www.metoffice.gov.uk/hadobs}{www.metoffice.gov.uk/hadobs}. Choose observations which are
-valid for the period of your test run because the observation operator compares
-the model and observations for a matching date and time. 
+\item Download some EN4 data from \href{http://www.metoffice.gov.uk/hadobs}{www.metoffice.gov.uk/hadobs}.
+  Choose observations which are valid for the period of your test run because
+  the observation operator compares the model and observations for a matching date and time. 
 
 \item Compile the OBSTOOLS code using: 
@@ -79,38 +78,31 @@
 \end{cmds}
 
-\item Include the following in the NEMO namelist to run the observation
-operator on this data:
+\item Include the following in the NEMO namelist to run the observation operator on this data:
 \end{enumerate}
 
-%------------------------------------------namobs_example-----------------------------------------------------
-%
-%\nlst{namobs_example}
-%-------------------------------------------------------------------------------------------------------------
-
-Options are defined through the  \ngn{namobs} namelist variables.
-The options \np{ln\_t3d} and \np{ln\_s3d} switch on the temperature and salinity
-profile observation operator code. The filename or array of filenames are
-specified using the \np{cn\_profbfiles} variable. The model grid points for a
-particular  observation latitude and longitude are found using the grid
-searching part of the code. This can be expensive, particularly for large
-numbers of observations, setting \np{ln\_grid\_search\_lookup} allows the use of
-a lookup table which is saved into an ``xypos`` file (or files). This will need
-to be generated the first time if it does not exist in the run directory.
+Options are defined through the \ngn{namobs} namelist variables.
+The options \np{ln\_t3d} and \np{ln\_s3d} switch on the temperature and salinity profile observation operator code.
+The filename or array of filenames are specified using the \np{cn\_profbfiles} variable.
+The model grid points for a particular observation latitude and longitude are found using
+the grid searching part of the code.
+This can be expensive, particularly for large numbers of observations,
+setting \np{ln\_grid\_search\_lookup} allows the use of a lookup table which
+is saved into an ``xypos`` file (or files).
+This will need to be generated the first time if it does not exist in the run directory.
 However, once produced it will significantly speed up future grid searches.
-Setting \np{ln\_grid\_global} means that the code distributes the observations
-evenly between processors. Alternatively each processor will work with
-observations located within the model subdomain (see section~\autoref{subsec:OBS_parallel}).
-
-A number of utilities are now provided to plot the feedback files, convert and
-recombine the files. These are explained in more detail in section~\autoref{sec:OBS_obsutils}.
-Utilites to convert other input data formats into the feedback format are also 
-described in section~\autoref{sec:OBS_obsutils}.
+Setting \np{ln\_grid\_global} means that the code distributes the observations evenly between processors.
+Alternatively each processor will work with observations located within the model subdomain
+(see section~\autoref{subsec:OBS_parallel}).
+
+A number of utilities are now provided to plot the feedback files, convert and recombine the files.
+These are explained in more detail in section~\autoref{sec:OBS_obsutils}.
+Utilites to convert other input data formats into the feedback format are also described in
+section~\autoref{sec:OBS_obsutils}.
 
 \section{Technical details (feedback type observation file headers)}
 \label{sec:OBS_details}
 
-Here we show a more complete example namelist  \ngn{namobs} and also show the NetCDF headers
-of the observation
-files that may be used with the observation operator
+Here we show a more complete example namelist \ngn{namobs} and also show the NetCDF headers of
+the observation files that may be used with the observation operator.
 
 %------------------------------------------namobs--------------------------------------------------------
@@ -119,10 +111,8 @@
 %-------------------------------------------------------------------------------------------------------------
 
-The observation operator code uses the "feedback" observation file format for
-all data types. All the
-observation files must be in NetCDF format. Some example headers (produced using
-\mbox{\textit{ncdump~-h}}) for profile
-data, sea level anomaly and sea surface temperature are in the following
-subsections.
+The observation operator code uses the "feedback" observation file format for all data types.
+All the observation files must be in NetCDF format.
+Some example headers (produced using \mbox{\textit{ncdump~-h}}) for profile data, sea level anomaly and
+sea surface temperature are in the following subsections.
 
 \subsection{Profile feedback}
@@ -406,9 +396,8 @@
 \end{clines}
 
-The mean dynamic
-topography (MDT) must be provided in a separate file defined on the model grid
- called \ifile{slaReferenceLevel}. The MDT is required in
-order to produce the model equivalent sea level anomaly from the model sea
-surface height. Below is an example header for this file (on the ORCA025 grid).
+The mean dynamic topography (MDT) must be provided in a separate file defined on
+the model grid called \ifile{slaReferenceLevel}.
+The MDT is required in order to produce the model equivalent sea level anomaly from the model sea surface height.
+Below is an example header for this file (on the ORCA025 grid).
 
 \begin{clines}
@@ -551,12 +540,16 @@
 \subsection{Horizontal interpolation and averaging methods}
 
-For most observation types, the horizontal extent of the observation is small compared to the model grid size
-and so the model equivalent of the observation is calculated by interpolating from the four surrounding grid
-points to the observation location. Some satellite observations (e.g. microwave satellite SST data, or satellite SSS data)
-have a footprint which is similar in size or larger than the model grid size (particularly when the grid size is small). 
-In those cases the model counterpart should be calculated by averaging the model grid points over the same size as the footprint.
-NEMO therefore has the capability to specify either an interpolation or an averaging (for surface observation types only). 
-
-The main namelist option associated with the interpolation/averaging is \np{nn\_2dint}. This default option can be set to values from 0 to 6. 
+For most observation types, the horizontal extent of the observation is small compared to the model grid size and so
+the model equivalent of the observation is calculated by interpolating from
+the four surrounding grid points to the observation location.
+Some satellite observations (e.g. microwave satellite SST data, or satellite SSS data) have a footprint which
+is similar in size or larger than the model grid size (particularly when the grid size is small).
+In those cases the model counterpart should be calculated by averaging the model grid points over
+the same size as the footprint.
+NEMO therefore has the capability to specify either an interpolation or an averaging
+(for surface observation types only). 
+
+The main namelist option associated with the interpolation/averaging is \np{nn\_2dint}.
+This default option can be set to values from 0 to 6.
 Values between 0 to 4 are associated with interpolation while values 5 or 6 are associated with averaging.
 \begin{itemize}
@@ -566,22 +559,23 @@
 \item \np{nn\_2dint}\forcode{ = 3}: Bilinear remapping interpolation (general grid)
 \item \np{nn\_2dint}\forcode{ = 4}: Polynomial interpolation
-\item \np{nn\_2dint}\forcode{ = 5}: Radial footprint averaging with diameter specified in the namelist as \np{rn\_???\_avglamscl} in degrees or metres (set using \np{ln\_???\_fp\_indegs})
-\item \np{nn\_2dint}\forcode{ = 6}: Rectangular footprint averaging with E/W and N/S size specified in the namelist as \np{rn\_???\_avglamscl} and \np{rn\_???\_avgphiscl} in degrees or metres (set using \np{ln\_???\_fp\_indegs})
+\item \np{nn\_2dint}\forcode{ = 5}: Radial footprint averaging with diameter specified in the namelist as
+  \np{rn\_???\_avglamscl} in degrees or metres (set using \np{ln\_???\_fp\_indegs})
+\item \np{nn\_2dint}\forcode{ = 6}: Rectangular footprint averaging with E/W and N/S size specified in
+  the namelist as \np{rn\_???\_avglamscl} and \np{rn\_???\_avgphiscl} in degrees or metres
+  (set using \np{ln\_???\_fp\_indegs})
 \end{itemize}
-The ??? in the last two options indicate these options should be specified for each observation type for which the averaging is to be performed (see namelist example above).
-The \np{nn\_2dint} default option can be overridden for surface observation types using namelist values \np{nn\_2dint\_???} where ??? is one of sla,sst,sss,sic.
+The ??? in the last two options indicate these options should be specified for each observation type for
+which the averaging is to be performed (see namelist example above).
+The \np{nn\_2dint} default option can be overridden for surface observation types using
+namelist values \np{nn\_2dint\_???} where ??? is one of sla,sst,sss,sic.
 
 Below is some more detail on the various options for interpolation and averaging available in NEMO.
 
 \subsubsection{Horizontal interpolation}
-Consider an observation point ${\rm P}$ with 
-with longitude and latitude $({\lambda_{}}_{\rm P}, \phi_{\rm P})$ and the 
-four nearest neighbouring model grid points ${\rm A}$, ${\rm B}$, ${\rm C}$ 
-and ${\rm D}$ with longitude and latitude ($\lambda_{\rm A}$, $\phi_{\rm A}$),
-($\lambda_{\rm B}$, $\phi_{\rm B}$) etc.
-All horizontal interpolation methods implemented in NEMO
-estimate the value of a model variable $x$ at point $P$ as
-a weighted linear combination of the values of the model 
-variables at the grid points ${\rm A}$, ${\rm B}$ etc.:
+Consider an observation point ${\rm P}$ with with longitude and latitude $({\lambda_{}}_{\rm P}, \phi_{\rm P})$ and
+the four nearest neighbouring model grid points ${\rm A}$, ${\rm B}$, ${\rm C}$ and ${\rm D}$ with
+longitude and latitude ($\lambda_{\rm A}$, $\phi_{\rm A}$),($\lambda_{\rm B}$, $\phi_{\rm B}$) etc.
+All horizontal interpolation methods implemented in NEMO estimate the value of a model variable $x$ at point $P$ as
+a weighted linear combination of the values of the model variables at the grid points ${\rm A}$, ${\rm B}$ etc.:
 \begin{eqnarray}
 {x_{}}_{\rm P} & \hspace{-2mm} = \hspace{-2mm} & 
@@ -591,7 +585,6 @@
                    {w_{}}_{\rm D} {x_{}}_{\rm D} \right)
 \end{eqnarray}
-where ${w_{}}_{\rm A}$, ${w_{}}_{\rm B}$ etc. are the respective weights for the 
-model field at points ${\rm A}$, ${\rm B}$ etc., and 
-$w = {w_{}}_{\rm A} + {w_{}}_{\rm B} + {w_{}}_{\rm C} + {w_{}}_{\rm D}$.
+where ${w_{}}_{\rm A}$, ${w_{}}_{\rm B}$ etc. are the respective weights for the model field at
+points ${\rm A}$, ${\rm B}$ etc., and $w = {w_{}}_{\rm A} + {w_{}}_{\rm B} + {w_{}}_{\rm C} + {w_{}}_{\rm D}$.
 
 Four different possibilities are available for computing the weights.
@@ -599,9 +592,9 @@
 \begin{enumerate}
 
-\item[1.] {\bf Great-Circle distance-weighted interpolation.} The weights
-  are computed as a function of the great-circle distance $s(P, \cdot)$ 
-  between $P$ and the model grid points $A$, $B$ etc. For example, 
-  the weight given to the field ${x_{}}_{\rm A}$ is specified as the 
-  product of the distances from ${\rm P}$ to the other points:
+\item[1.] {\bf Great-Circle distance-weighted interpolation.}
+  The weights are computed as a function of the great-circle distance $s(P, \cdot)$ between $P$ and
+  the model grid points $A$, $B$ etc.
+  For example, the weight given to the field ${x_{}}_{\rm A}$ is specified as the product of the distances
+  from ${\rm P}$ to the other points:
   \begin{eqnarray}
   {w_{}}_{\rm A} = s({\rm P}, {\rm B}) \, s({\rm P}, {\rm C}) \, s({\rm P}, {\rm D})
@@ -619,7 +612,6 @@
    \end{eqnarray}
    and $M$ corresponds to $B$, $C$ or $D$.
-   A more stable form of the great-circle distance formula for
-   small distances ($x$ near 1) involves the arcsine function
-   ($e.g.$ see p.~101 of \citet{Daley_Barker_Bk01}:
+   A more stable form of the great-circle distance formula for small distances ($x$ near 1)
+   involves the arcsine function ($e.g.$ see p.~101 of \citet{Daley_Barker_Bk01}:
    \begin{eqnarray}
    s\left( {\rm P}, {\rm M} \right) 
@@ -651,7 +643,6 @@
   \end{eqnarray}
 
-\item[2.] {\bf Great-Circle distance-weighted interpolation with small angle
-  approximation.} Similar to the previous interpolation but with the
-  distance $s$ computed as
+\item[2.] {\bf Great-Circle distance-weighted interpolation with small angle approximation.}
+  Similar to the previous interpolation but with the distance $s$ computed as
   \begin{eqnarray}
     s\left( {\rm P}, {\rm M} \right) 
@@ -663,12 +654,11 @@
   where $M$ corresponds to $A$, $B$, $C$ or $D$.
 
-\item[3.] {\bf Bilinear interpolation for a regular spaced grid.} The
-  interpolation is split into two 1D interpolations in the longitude
-  and latitude directions, respectively.
-
-\item[4.] {\bf Bilinear remapping interpolation for a general grid.} An
-  iterative scheme that involves first mapping a quadrilateral cell
-  into a cell with coordinates (0,0), (1,0), (0,1) and (1,1). This
-  method is based on the SCRIP interpolation package \citep{Jones_1998}.
+\item[3.] {\bf Bilinear interpolation for a regular spaced grid.}
+  The interpolation is split into two 1D interpolations in the longitude and latitude directions, respectively.
+
+\item[4.] {\bf Bilinear remapping interpolation for a general grid.}
+  An iterative scheme that involves first mapping a quadrilateral cell into
+  a cell with coordinates (0,0), (1,0), (0,1) and (1,1).
+  This method is based on the SCRIP interpolation package \citep{Jones_1998}.
   
 \end{enumerate}
@@ -678,12 +668,22 @@
 For each surface observation type:
 \begin{itemize}
-\item The standard grid-searching code is used to find the nearest model grid point to the observation location (see next subsection).
-\item The maximum number of grid points is calculated in the local grid domain for which the averaging is likely need to cover.
-\item The lats/longs of the grid points surrounding the nearest model grid box are extracted using existing mpi routines.
-\item The weights for each grid point associated with each observation are calculated, either for radial or rectangular footprints. For grid points completely within the footprint, the weight is one; for grid points completely outside the footprint, the weight is zero. For grid points which are partly within the footprint the ratio between the area of the footprint within the grid box and the total area of the grid box is used as the weight.
-\item The weighted average of the model grid points associated with each observation is calculated, and this is then given as the model counterpart of the observation.
+\item The standard grid-searching code is used to find the nearest model grid point to the observation location
+  (see next subsection).
+\item The maximum number of grid points is calculated in the local grid domain for which
+  the averaging is likely need to cover.
+\item The lats/longs of the grid points surrounding the nearest model grid box are extracted using
+  existing mpi routines.
+\item The weights for each grid point associated with each observation are calculated,
+  either for radial or rectangular footprints.
+  For grid points completely within the footprint, the weight is one;
+  for grid points completely outside the footprint, the weight is zero.
+  For grid points which are partly within the footprint the ratio between the area of the footprint within
+  the grid box and the total area of the grid box is used as the weight.
+\item The weighted average of the model grid points associated with each observation is calculated,
+  and this is then given as the model counterpart of the observation.
 \end{itemize}
 
-Examples of the weights calculated for an observation with rectangular and radial footprints are shown in Figs.~\autoref{fig:obsavgrec} and~\autoref{fig:obsavgrad}.
+Examples of the weights calculated for an observation with rectangular and radial footprints are shown in
+Figs.~\autoref{fig:obsavgrec} and~\autoref{fig:obsavgrad}.
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -691,5 +691,6 @@
 \includegraphics[width=0.90\textwidth]{Fig_OBS_avg_rec}
 \caption{      \protect\label{fig:obsavgrec}
-Weights associated with each model grid box (blue lines and numbers) for an observation at -170.5E, 56.0N with a rectangular footprint of 1\deg x 1\deg.}
+  Weights associated with each model grid box (blue lines and numbers)
+  for an observation at -170.5E, 56.0N with a rectangular footprint of 1\deg x 1\deg.}
 \end{center}      \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -699,5 +700,6 @@
 \includegraphics[width=0.90\textwidth]{Fig_OBS_avg_rad}
 \caption{      \protect\label{fig:obsavgrad}
-Weights associated with each model grid box (blue lines and numbers) for an observation at -170.5E, 56.0N with a radial footprint with diameter 1\deg.} 
+  Weights associated with each model grid box (blue lines and numbers)
+  for an observation at -170.5E, 56.0N with a radial footprint with diameter 1\deg.} 
 \end{center}      \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -706,25 +708,15 @@
 \subsection{Grid search}
 
-For many grids used by the NEMO model, such as the ORCA family, 
-the horizontal grid coordinates $i$ and $j$ are not simple functions 
-of latitude and longitude. Therefore, it is not always straightforward 
-to determine the grid points surrounding any given observational position.
-Before the interpolation can be performed, a search 
-algorithm is then required to determine the corner points of 
+For many grids used by the NEMO model, such as the ORCA family, the horizontal grid coordinates $i$ and $j$ are not simple functions of latitude and longitude.
+Therefore, it is not always straightforward to determine the grid points surrounding any given observational position.
+Before the interpolation can be performed, a search algorithm is then required to determine the corner points of 
 the quadrilateral cell in which the observation is located.
-This is the most difficult and time consuming part of the 
-2D interpolation procedure. 
-A robust test for determining if an observation falls
-within a given quadrilateral cell is as follows. Let 
-${\rm P}({\lambda_{}}_{\rm P} ,{\phi_{}}_{\rm P} )$ denote the observation point,
-and let ${\rm A}({\lambda_{}}_{\rm A} ,{\phi_{}}_{\rm A} )$,
-${\rm B}({\lambda_{}}_{\rm B} ,{\phi_{}}_{\rm B} )$,
-${\rm C}({\lambda_{}}_{\rm C} ,{\phi_{}}_{\rm C} )$ 
-and 
-${\rm D}({\lambda_{}}_{\rm D} ,{\phi_{}}_{\rm D} )$ denote
-the bottom left, bottom right, top left and top right
-corner points of the cell, respectively. 
-To determine if P is inside 
-the cell, we verify that the cross-products 
+This is the most difficult and time consuming part of the 2D interpolation procedure. 
+A robust test for determining if an observation falls within a given quadrilateral cell is as follows.
+Let ${\rm P}({\lambda_{}}_{\rm P} ,{\phi_{}}_{\rm P} )$ denote the observation point,
+and let ${\rm A}({\lambda_{}}_{\rm A} ,{\phi_{}}_{\rm A} )$, ${\rm B}({\lambda_{}}_{\rm B} ,{\phi_{}}_{\rm B} )$,
+${\rm C}({\lambda_{}}_{\rm C} ,{\phi_{}}_{\rm C} )$ and ${\rm D}({\lambda_{}}_{\rm D} ,{\phi_{}}_{\rm D} )$
+denote the bottom left, bottom right, top left and top right corner points of the cell, respectively. 
+To determine if P is inside the cell, we verify that the cross-products 
 \begin{eqnarray}
 \begin{array}{lllll}
@@ -752,35 +744,29 @@
 \label{eq:cross}
 \end{eqnarray}
-point in the opposite direction to the unit normal 
-$\widehat{\bf k}$ (i.e., that the coefficients of 
-$\widehat{\bf k}$ are negative),
-where ${{\bf r}_{}}_{\rm PA}$, ${{\bf r}_{}}_{\rm PB}$, 
-etc. correspond to the vectors between points P and A, 
-P and B, etc.. The method used is
-similar to the method used in
-the SCRIP interpolation package \citep{Jones_1998}.
-
-In order to speed up the grid search, there is the possibility to construct 
-a lookup table for a user specified resolution. This lookup
-table contains the lower and upper bounds on the $i$ and $j$ indices
-to be searched for on a regular grid. For each observation position,
-the closest point on the regular grid of this position is computed and
-the $i$ and $j$ ranges of this point searched to determine the precise
-four points surrounding the observation. 
+point in the opposite direction to the unit normal $\widehat{\bf k}$
+(i.e., that the coefficients of $\widehat{\bf k}$ are negative),
+where ${{\bf r}_{}}_{\rm PA}$, ${{\bf r}_{}}_{\rm PB}$, etc. correspond to
+the vectors between points P and A, P and B, etc..
+The method used is similar to the method used in the SCRIP interpolation package \citep{Jones_1998}.
+
+In order to speed up the grid search, there is the possibility to construct a lookup table for a user specified resolution.
+This lookup table contains the lower and upper bounds on the $i$ and $j$ indices to
+be searched for on a regular grid.
+For each observation position, the closest point on the regular grid of this position is computed and
+the $i$ and $j$ ranges of this point searched to determine the precise four points surrounding the observation. 
 
 \subsection{Parallel aspects of horizontal interpolation}
 \label{subsec:OBS_parallel}
 
-For horizontal interpolation, there is the basic problem that the
-observations are unevenly distributed on the globe. In numerical
-models, it is common to divide the model grid into subgrids (or
-domains) where each subgrid is executed on a single processing element
-with explicit message passing for exchange of information along the
-domain boundaries when running on a massively parallel processor (MPP)
-system. This approach is used by \NEMO.
-
-For observations there is no natural distribution since the
-observations are not equally distributed on the globe. 
-Two options have been made available: 1) geographical distribution;
+For horizontal interpolation, there is the basic problem that
+the observations are unevenly distributed on the globe.
+In numerical models, it is common to divide the model grid into subgrids (or domains) where
+each subgrid is executed on a single processing element with explicit message passing for
+exchange of information along the domain boundaries when running on a massively parallel processor (MPP) system.
+This approach is used by \NEMO.
+
+For observations there is no natural distribution since the observations are not equally distributed on the globe. 
+Two options have been made available:
+1) geographical distribution;
 and 2) round-robin.
 
@@ -791,24 +777,22 @@
 \includegraphics[width=10cm,height=12cm,angle=-90.]{Fig_ASM_obsdist_local}
 \caption{      \protect\label{fig:obslocal}
-Example of the distribution of observations with the geographical distribution of observational data.} 
+  Example of the distribution of observations with the geographical distribution of observational data.} 
 \end{center}      \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
-This is the simplest option in which the observations are distributed according 
-to the domain of the grid-point parallelization. \autoref{fig:obslocal}
-shows an example of the distribution of the {\em in situ} data on processors 
-with a different colour for each observation
-on a given processor for a 4 $\times$ 2 decomposition with ORCA2. 
+This is the simplest option in which the observations are distributed according to
+the domain of the grid-point parallelization.
+\autoref{fig:obslocal} shows an example of the distribution of the {\em in situ} data on processors with
+a different colour for each observation on a given processor for a 4 $\times$ 2 decomposition with ORCA2. 
 The grid-point domain decomposition is clearly visible on the plot.
 
-The advantage of this approach is that all
-information needed for horizontal interpolation is available without
-any MPP communication. Of course, this is under the assumption that 
-we are only using a $2 \times 2$ grid-point stencil for the interpolation 
-(e.g., bilinear interpolation). For higher order interpolation schemes this
-is no longer valid. A disadvantage with the above scheme is that the number of
-observations on each processor can be very different. If the cost of
-the actual interpolation is expensive relative to the communication of
-data needed for interpolation, this could lead to load imbalance.
+The advantage of this approach is that all information needed for horizontal interpolation is available without
+any MPP communication.
+Of course, this is under the assumption that we are only using a $2 \times 2$ grid-point stencil for
+the interpolation (e.g., bilinear interpolation).
+For higher order interpolation schemes this is no longer valid.
+A disadvantage with the above scheme is that the number of observations on each processor can be very different.
+If the cost of the actual interpolation is expensive relative to the communication of data needed for interpolation,
+this could lead to load imbalance.
 
 \subsubsection{Round-robin distribution of observations among processors}
@@ -818,27 +802,23 @@
 \includegraphics[width=10cm,height=12cm,angle=-90.]{Fig_ASM_obsdist_global}
 \caption{      \protect\label{fig:obsglobal}
-Example of the distribution of observations with the round-robin distribution of observational data.}
+  Example of the distribution of observations with the round-robin distribution of observational data.}
 \end{center}     \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
-An alternative approach is to distribute the observations equally
-among processors and use message passing in order to retrieve 
-the stencil for interpolation. The simplest distribution of the observations 
-is to distribute them using a round-robin scheme. \autoref{fig:obsglobal}
-shows the distribution of the {\em in situ} data on processors for the
-round-robin distribution of observations with a different colour for
-each observation on a given processor for a 4 $\times$ 2 decomposition 
-with ORCA2 for the same input data as in \autoref{fig:obslocal}.
+An alternative approach is to distribute the observations equally among processors and
+use message passing in order to retrieve the stencil for interpolation.
+The simplest distribution of the observations is to distribute them using a round-robin scheme.
+\autoref{fig:obsglobal} shows the distribution of the {\em in situ} data on processors for
+the round-robin distribution of observations with a different colour for each observation on a given processor for
+a 4 $\times$ 2 decomposition with ORCA2 for the same input data as in \autoref{fig:obslocal}.
 The observations are now clearly randomly distributed on the globe.
-In order to be able to perform horizontal interpolation in this case, 
-a subroutine has been developed that retrieves any grid points in the 
-global space.
+In order to be able to perform horizontal interpolation in this case,
+a subroutine has been developed that retrieves any grid points in the global space.
 
 \subsection{Vertical interpolation operator}
 
-Vertical interpolation is achieved using either a cubic spline or
-linear interpolation. For the cubic spline, the top and
-bottom boundary conditions for the second derivative of the 
-interpolating polynomial in the spline are set to zero.
+Vertical interpolation is achieved using either a cubic spline or linear interpolation.
+For the cubic spline, the top and bottom boundary conditions for the second derivative of
+the interpolating polynomial in the spline are set to zero.
 At the bottom boundary, this is done using the land-ocean mask.
 
@@ -856,22 +836,26 @@
 \subsection{Concept}
 
-The obs oper maps model variables to observation space. It is possible to apply this mapping
-without running the model. The software which performs this functionality is known as the
-\textbf{offline obs oper}. The obs oper is divided into three stages. An initialisation phase,
-an interpolation phase and an output phase. The implementation of which is outlined in the
-previous sections. During the interpolation phase the offline obs oper populates the model
-arrays by reading saved model fields from disk.
-
-There are two ways of exploiting this offline capacity. The first is to mimic the behaviour of
-the online system by supplying model fields at regular intervals between the start and the end
-of the run. This approach results in a single model counterpart per observation. This kind of
-usage produces feedback files the same file format as the online obs oper. 
-The second is to take advantage of the offline setting in which multiple model counterparts can
-be calculated per observation. In this case it is possible to consider all forecasts verifying
-at the same time. By forecast, I mean any method which produces an estimate of physical reality
-which is not an observed value. In the case of class 4 files this means forecasts, analyses, persisted
-analyses and climatological values verifying at the same time. Although the class 4 file format
-doesn't account for multiple ensemble members or multiple experiments per observation, it is possible
-to include these components in the same or multiple files.
+The obs oper maps model variables to observation space.
+It is possible to apply this mapping without running the model.
+The software which performs this functionality is known as the \textbf{offline obs oper}.
+The obs oper is divided into three stages.
+An initialisation phase, an interpolation phase and an output phase.
+The implementation of which is outlined in the previous sections.
+During the interpolation phase the offline obs oper populates the model arrays by
+reading saved model fields from disk.
+
+There are two ways of exploiting this offline capacity.
+The first is to mimic the behaviour of the online system by supplying model fields at
+regular intervals between the start and the end of the run.
+This approach results in a single model counterpart per observation.
+This kind of usage produces feedback files the same file format as the online obs oper.
+The second is to take advantage of the offline setting in which
+multiple model counterparts can be calculated per observation.
+In this case it is possible to consider all forecasts verifying at the same time.
+By forecast, I mean any method which produces an estimate of physical reality which is not an observed value.
+In the case of class 4 files this means forecasts, analyses, persisted analyses and
+climatological values verifying at the same time.
+Although the class 4 file format doesn't account for multiple ensemble members or
+multiple experiments per observation, it is possible to include these components in the same or multiple files.
 
 %--------------------------------------------------------------------------------------------------------
@@ -883,8 +867,8 @@
 \subsubsection{Building}
 
-In addition to \emph{OPA\_SRC} the offline obs oper requires the inclusion
-of the \emph{OOO\_SRC} directory. \emph{OOO\_SRC} contains a replacement \mdl{nemo} and
-\mdl{nemogcm} which overwrites the resultant \textbf{nemo.exe}. This is the approach taken
-by \emph{SAS\_SRC} and \emph{OFF\_SRC}.
+In addition to \emph{OPA\_SRC} the offline obs oper requires the inclusion of the \emph{OOO\_SRC} directory.
+\emph{OOO\_SRC} contains a replacement \mdl{nemo} and \mdl{nemogcm} which
+overwrites the resultant \textbf{nemo.exe}.
+This is the approach taken by \emph{SAS\_SRC} and \emph{OFF\_SRC}.
 
 %--------------------------------------------------------------------------------------------------------
@@ -898,7 +882,7 @@
 \subsubsection{Quick script}
 
-A useful Python utility to control the namelist options can be found in \textbf{OBSTOOLS/OOO}. The
-functions which locate model fields and observation files can be manually specified. The package
-can be installed by appropriate use of the included setup.py script.
+A useful Python utility to control the namelist options can be found in \textbf{OBSTOOLS/OOO}.
+The functions which locate model fields and observation files can be manually specified.
+The package can be installed by appropriate use of the included setup.py script.
 
 Documentation can be auto-generated by Sphinx by running \emph{make html} in the \textbf{doc} directory.
@@ -908,8 +892,8 @@
 %--------------------------------------------------------------------------------------------------------
 \subsection{Configuring the offline observation operator}
-The observation files and settings understood by \textbf{namobs} have been outlined in the online
-obs oper section. In addition there are two further namelists wich control the operation of the offline
-obs oper. \textbf{namooo} which controls the input model fields and \textbf{namcl4} which controls the
-production of class 4 files. 
+The observation files and settings understood by \textbf{namobs} have been outlined in the online obs oper section.
+In addition there are two further namelists wich control the operation of the offline obs oper.
+\textbf{namooo} which controls the input model fields and \textbf{namcl4} which
+controls the production of class 4 files. 
 
 \subsubsection{Single field}
@@ -917,11 +901,11 @@
 In offline mode model arrays are populated at appropriate time steps via input files.
 At present, \textbf{tsn} and \textbf{sshn} are populated by the default read routines. 
-These routines will be expanded upon in future versions to allow the specification of any
-model variable. As such, input files must be global versions of the model domain with
+These routines will be expanded upon in future versions to allow the specification of any model variable.
+As such, input files must be global versions of the model domain with
 \textbf{votemper}, \textbf{vosaline} and optionally \textbf{sshn} present.
 
-For each field read there must be an entry in the \textbf{namooo} namelist specifying the
-name of the file to read and the index along the \emph{time\_counter}. For example, to
-read the second time counter from a single file the namelist would be.
+For each field read there must be an entry in the \textbf{namooo} namelist specifying
+the name of the file to read and the index along the \emph{time\_counter}.
+For example, to read the second time counter from a single file the namelist would be.
 
 \begin{forlines}
@@ -939,7 +923,7 @@
 \subsubsection{Multiple fields per run}
 
-Model field iteration is controlled via \textbf{nn\_ooo\_freq} which specifies
-the number of model steps at which the next field gets read. For example, if
-12 hourly fields are to be interpolated in a setup where 288 steps equals 24 hours.
+Model field iteration is controlled via \textbf{nn\_ooo\_freq} which
+specifies the number of model steps at which the next field gets read.
+For example, if 12 hourly fields are to be interpolated in a setup where 288 steps equals 24 hours.
 
 \begin{forlines}
@@ -957,6 +941,6 @@
 \end{forlines}
 
-The above namelist will result in feedback files whose first 12 hours contain
-the first field of foo.nc and the second 12 hours contain the second field.
+The above namelist will result in feedback files whose first 12 hours contain the first field of foo.nc and
+the second 12 hours contain the second field.
 
 %\begin{framed}
@@ -964,13 +948,12 @@
 %\end{framed}
 
-It is easy to see how a collection of fields taken fron a number of files 
-at different indices can be combined at a particular frequency in time to 
-generate a pseudo model evolution. As long as all that is needed is a single
-model counterpart at a regular interval then namooo is all that needs to
-be edited. However, a far more interesting approach can be taken in which
-multiple forecasts, analyses, persisted analyses and climatologies are
-considered against the same set of observations. For this a slightly more
-complicated approach is needed. It is referred to as \emph{Class 4} since
-it is the fourth metric defined by the GODAE intercomparison project.
+It is easy to see how a collection of fields taken fron a number of files at different indices can be combined at
+a particular frequency in time to generate a pseudo model evolution.
+As long as all that is needed is a single model counterpart at a regular interval then
+namooo is all that needs to be edited.
+However, a far more interesting approach can be taken in which multiple forecasts, analyses, persisted analyses and
+climatologies are considered against the same set of observations.
+For this a slightly more complicated approach is needed.
+It is referred to as \emph{Class 4} since it is the fourth metric defined by the GODAE intercomparison project.
 
 %--------------------------------------------------------------------------------------------------------
@@ -979,17 +962,15 @@
 \subsubsection{Multiple model counterparts per observation a.k.a Class 4}
 
-A generalisation of feedback files to allow multiple model components per observation. For a single
-observation, as well as previous forecasts verifying at the same time there are also analyses, persisted
-analyses and climatologies. 
-
-
-The above namelist performs two basic functions. It organises the fields
-given in \textbf{namooo} into groups so that observations can be matched
-up multiple times. It also controls the metadata and the output variable
-of the class 4 file when a write routine is called.
+A generalisation of feedback files to allow multiple model components per observation.
+For a single observation, as well as previous forecasts verifying at the same time
+there are also analyses, persisted analyses and climatologies. 
+
+
+The above namelist performs two basic functions.
+It organises the fields given in \textbf{namooo} into groups so that observations can be matched up multiple times.
+It also controls the metadata and the output variable of the class 4 file when a write routine is called.
 
 %\begin{framed}
-\textbf{Note: ln\_cl4} must be set to \forcode{.true.} in \textbf{namobs} 
-to use class 4 outputs.
+\textbf{Note: ln\_cl4} must be set to \forcode{.true.} in \textbf{namobs} to use class 4 outputs.
 %\end{framed}
 
@@ -1004,62 +985,58 @@
 \noindent
 \linebreak
-Much of the namelist is devoted to specifying this convention. The
-following namelist settings control the elements of the output
-file names. Each should be specified as a single string of character data.
+Much of the namelist is devoted to specifying this convention.
+The following namelist settings control the elements of the output file names.
+Each should be specified as a single string of character data.
 
 \begin{description}
 \item[cl4\_prefix]
-Prefix for class 4 files e.g. class4
+  Prefix for class 4 files e.g. class4
 \item[cl4\_date]
-YYYYMMDD validity date
+  YYYYMMDD validity date
 \item[cl4\_sys]
-The name of the class 4 model system e.g. FOAM
+  The name of the class 4 model system e.g. FOAM
 \item[cl4\_cfg]
-The name of the class 4 model configuration e.g. orca025
+  The name of the class 4 model configuration e.g. orca025
 \item[cl4\_vn]
-The name of the class 4 model version e.g. 12.0
+  The name of the class 4 model version e.g. 12.0
 \end{description}
 
 \noindent
-The kind is specified by the observation type internally to the obs oper. The processor
-number is specified internally in NEMO. 
+The kind is specified by the observation type internally to the obs oper.
+The processor number is specified internally in NEMO. 
 
 \subsubsection{Class 4 file global attributes}
 
-Global attributes necessary to fulfill the class 4 file definition. These
-are also useful pieces of information when collaborating with external
-partners.
+Global attributes necessary to fulfill the class 4 file definition.
+These are also useful pieces of information when collaborating with external partners.
 
 \begin{description}
 \item[cl4\_contact]
-Contact email for class 4 files.
+  Contact email for class 4 files.
 \item[cl4\_inst]
-The name of the producers institution.
+  The name of the producers institution.
 \item[cl4\_cfg]
-The name of the class 4 model configuration e.g. orca025
+  The name of the class 4 model configuration e.g. orca025
 \item[cl4\_vn]
-The name of the class 4 model version e.g. 12.0
+  The name of the class 4 model version e.g. 12.0
 \end{description}
 
 \noindent
-The obs\_type,
-creation date and validity time are specified internally to the obs oper.
+The obs\_type, creation date and validity time are specified internally to the obs oper.
 
 \subsubsection{Class 4 model counterpart configuration}
 
-As seen previously it is possible to perform a single sweep of the
-obs oper and specify a collection of model fields equally spaced 
-along that sweep. In the class 4 case the single sweep is replaced
-with multiple sweeps and a certain ammount of book keeping is
-needed to ensure each model counterpart makes its way to the 
-correct piece of memory in the output files.
+As seen previously it is possible to perform a single sweep of the obs oper and
+specify a collection of model fields equally spaced along that sweep.
+In the class 4 case the single sweep is replaced with multiple sweeps and
+a certain ammount of book keeping is needed to ensure each model counterpart makes its way to
+the correct piece of memory in the output files.
 
 \noindent
 \linebreak
-In terms of book keeping, the offline obs oper needs to know how many
-full sweeps need to be performed. This is specified via the 
-\textbf{cl4\_match\_len} variable and is the total number of model
-counterparts per observation. For example, a 3 forecasts plus 3 persistence
-fields plus an analysis field would be 7 counterparts per observation.
+In terms of book keeping, the offline obs oper needs to know how many full sweeps need to be performed.
+This is specified via the \textbf{cl4\_match\_len} variable and
+is the total number of model counterparts per observation.
+For example, a 3 forecasts plus 3 persistence fields plus an analysis field would be 7 counterparts per observation.
 
 \begin{forlines}
@@ -1067,6 +1044,6 @@
 \end{forlines}
 
-Then to correctly allocate a class 4 file the forecast axis must be defined. This
-is controlled via \textbf{cl4\_fcst\_len}, which in out above example would be 3.
+Then to correctly allocate a class 4 file the forecast axis must be defined.
+This is controlled via \textbf{cl4\_fcst\_len}, which in out above example would be 3.
 
 \begin{forlines}
@@ -1074,8 +1051,7 @@
 \end{forlines}
 
-Then for each model field it is necessary to designate what class 4 variable and
-index along the forecast dimension the model counterpart should be stored in the
-output file. As well as a value for that lead time in hours, this will be useful
-when interpreting the data afterwards. 
+Then for each model field it is necessary to designate what class 4 variable and index along
+the forecast dimension the model counterpart should be stored in the output file.
+As well as a value for that lead time in hours, this will be useful when interpreting the data afterwards. 
 
 \begin{forlines}
@@ -1086,7 +1062,7 @@
 \end{forlines}
 
-In terms of files and indices of fields inside each file the class 4 approach
-makes use of the \textbf{namooo} namelist. If our fields are in separate files
-with a single field per file our example inputs will be specified.
+In terms of files and indices of fields inside each file the class 4 approach makes use of
+the \textbf{namooo} namelist.
+If our fields are in separate files with a single field per file our example inputs will be specified.
 
 \begin{forlines}
@@ -1095,6 +1071,5 @@
 \end{forlines}
 
-When we combine all of the naming conventions, global attributes and i/o instructions
-the class 4 namelist becomes.
+When we combine all of the naming conventions, global attributes and i/o instructions the class 4 namelist becomes.
 
 \begin{forlines}
@@ -1150,22 +1125,22 @@
 \subsubsection{Climatology interpolation}
 
-The climatological counterpart is generated at the start of the run by restarting 
-the model from climatology through appropriate use of \textbf{namtsd}. To override
-the offline observation operator read routine and to take advantage of the restart
-settings, specify the first entry in \textbf{cl4\_vars} as "climatology". This will then
-pipe the restart from climatology into the output class 4 file. As in every other
-class 4 matchup the input file, input index and output index must be specified.
-These can be replaced with dummy data since they are not used but they must be
-present to cycle through the matchups correctly. 
+The climatological counterpart is generated at the start of the run by
+restarting the model from climatology through appropriate use of \textbf{namtsd}.
+To override the offline observation operator read routine and to take advantage of the restart settings,
+specify the first entry in \textbf{cl4\_vars} as "climatology".
+This will then pipe the restart from climatology into the output class 4 file.
+As in every other class 4 matchup the input file, input index and output index must be specified.
+These can be replaced with dummy data since they are not used but
+they must be present to cycle through the matchups correctly. 
 
 \subsection{Advanced usage}
 
-In certain cases it may be desirable to include both multiple model fields per
-observation window with multiple match ups per observation. This can be achieved
-by specifying \textbf{nn\_ooo\_freq} as well as the class 4 settings. Care must
-be taken in generating the ooo\_files list such that the files are arranged into
-consecutive blocks of single match ups. For example, 2 forecast fields 
-of 12 hourly data would result in 4 separate read operations but only 2 write
-operations, 1 per forecast.
+In certain cases it may be desirable to include both multiple model fields per observation window with
+multiple match ups per observation.
+This can be achieved by specifying \textbf{nn\_ooo\_freq} as well as the class 4 settings.
+Care must be taken in generating the ooo\_files list such that the files are arranged into
+consecutive blocks of single match ups.
+For example, 2 forecast fields of 12 hourly data would result in 4 separate read operations but
+only 2 write operations, 1 per forecast.
 
 \begin{forlines}
@@ -1175,7 +1150,6 @@
 \end{forlines}
 
-The above notation reveals the internal split between match up iterators and file
-iterators. This technique has not been used before so experimentation is needed
-before results can be trusted.
+The above notation reveals the internal split between match up iterators and file iterators.
+This technique has not been used before so experimentation is needed before results can be trusted.
 
 
@@ -1187,21 +1161,24 @@
 \label{sec:OBS_obsutils}
 
-Some tools for viewing and processing of observation and feedback files are provided in the
-NEMO repository for convenience. These include OBSTOOLS which are a collection of Fortran
-programs which are helpful to deal with feedback files. They do such tasks as observation file
-conversion, printing of file contents, some basic statistical analysis of feedback files. The
-other tool is an IDL program called dataplot which uses a graphical interface to visualise
-observations and feedback files. OBSTOOLS and dataplot are described in more detail below.  
+Some tools for viewing and processing of observation and feedback files are provided in
+the NEMO repository for convenience.
+These include OBSTOOLS which are a collection of Fortran programs which are helpful to deal with feedback files.
+They do such tasks as observation file conversion, printing of file contents,
+some basic statistical analysis of feedback files.
+The other tool is an IDL program called dataplot which uses a graphical interface to
+visualise observations and feedback files.
+OBSTOOLS and dataplot are described in more detail below.
 
 \subsection{Obstools}
 
-A series of Fortran utilities is provided with NEMO called OBSTOOLS. This are helpful in
-handling observation files and the feedback file output from the NEMO observation operator.
+A series of Fortran utilities is provided with NEMO called OBSTOOLS.
+This are helpful in handling observation files and the feedback file output from the NEMO observation operator.
 The utilities are as follows
 
 \subsubsection{c4comb}
 
-The program c4comb combines multiple class 4 files produced by individual processors in an
-MPI run of NEMO offline obs\_oper into a single class 4 file. The program is called in the following way:
+The program c4comb combines multiple class 4 files produced by individual processors in
+an MPI run of NEMO offline obs\_oper into a single class 4 file.
+The program is called in the following way:
 
 
@@ -1213,6 +1190,6 @@
 \subsubsection{corio2fb}
 
-The program corio2fb converts profile observation files from the Coriolis format to the
-standard feedback format. The program is called in the following way:
+The program corio2fb converts profile observation files from the Coriolis format to the standard feedback format.
+The program is called in the following way:
 
 \footnotesize
@@ -1223,6 +1200,6 @@
 \subsubsection{enact2fb}
 
-The program enact2fb converts profile observation files from the ENACT format to the standard
-feedback format. The program is called in the following way:
+The program enact2fb converts profile observation files from the ENACT format to the standard feedback format.
+The program is called in the following way:
 
 \footnotesize
@@ -1233,6 +1210,7 @@
 \subsubsection{fbcomb}
 
-The program fbcomb combines multiple feedback files produced by individual processors in an
-MPI run of NEMO into a single feedback file. The program is called in the following way:
+The program fbcomb combines multiple feedback files produced by individual processors in
+an MPI run of NEMO into a single feedback file.
+The program is called in the following way:
 
 \footnotesize
@@ -1243,6 +1221,6 @@
 \subsubsection{fbmatchup}
 
-The program fbmatchup will match observations from two feedback files. The program is called
-in the following way:
+The program fbmatchup will match observations from two feedback files.
+The program is called in the following way:
 
 \footnotesize
@@ -1254,6 +1232,6 @@
 
 The program fbprint will print the contents of a feedback file or files to standard output.
-Selected information can be output using optional arguments. The program is called in the
-following way:
+Selected information can be output using optional arguments.
+The program is called in the following way:
 
 \footnotesize
@@ -1282,6 +1260,6 @@
 \subsubsection{fbsel}
 
-The program fbsel will select or subsample observations. The program is called in the
-following way:
+The program fbsel will select or subsample observations.
+The program is called in the following way:
 
 \footnotesize
@@ -1292,6 +1270,6 @@
 \subsubsection{fbstat}
 
-The program fbstat will output summary statistics in different global areas into a number of
-files. The program is called in the following way:
+The program fbstat will output summary statistics in different global areas into a number of files.
+The program is called in the following way:
 
 \footnotesize
@@ -1302,6 +1280,7 @@
 \subsubsection{fbthin}
 
-The program fbthin will thin the data to 1 degree resolution. The code could easily be
-modified to thin to a different resolution. The program is called in the following way:
+The program fbthin will thin the data to 1 degree resolution.
+The code could easily be modified to thin to a different resolution.
+The program is called in the following way:
 
 \footnotesize
@@ -1312,6 +1291,6 @@
 \subsubsection{sla2fb}
 
-The program sla2fb will convert an AVISO SLA format file to feedback format. The program is
-called in the following way:
+The program sla2fb will convert an AVISO SLA format file to feedback format.
+The program is called in the following way:
 
 \footnotesize
@@ -1325,6 +1304,6 @@
 \subsubsection{vel2fb}
 
-The program vel2fb will convert TAO/PIRATA/RAMA currents files to feedback format. The program
-is called in the following way:
+The program vel2fb will convert TAO/PIRATA/RAMA currents files to feedback format.
+The program is called in the following way:
 
 \footnotesize
@@ -1339,7 +1318,8 @@
 \subsection{Dataplot}
 
-An IDL program called dataplot is included which uses a graphical interface to visualise
-observations and feedback files. It is possible to zoom in, plot individual profiles and
-calculate some basic statistics. To plot some data run IDL and then:
+An IDL program called dataplot is included which uses a graphical interface to
+visualise observations and feedback files.
+It is possible to zoom in, plot individual profiles and calculate some basic statistics.
+To plot some data run IDL and then:
 \footnotesize
 \begin{minted}{idl}
@@ -1347,7 +1327,7 @@
 \end{minted}
 
-To read multiple files into dataplot, for example multiple feedback files from different
-processors or from different days, the easiest method is to use the spawn command to generate
-a list of files which can then be passed to dataplot.
+To read multiple files into dataplot,
+for example multiple feedback files from different processors or from different days,
+the easiest method is to use the spawn command to generate a list of files which can then be passed to dataplot.
 \footnotesize
 \begin{minted}{idl}
@@ -1357,27 +1337,32 @@
 
 \autoref{fig:obsdataplotmain} shows the main window which is launched when dataplot starts.
-This is split into three parts. At the top there is a menu bar which contains a variety of
-drop down menus. Areas - zooms into prespecified regions; plot - plots the data as a
-timeseries or a T-S diagram if appropriate; Find - allows data to be searched; Config - sets
-various configuration options.
-
-The middle part is a plot of the geographical location of the observations. This will plot the
-observation value, the model background value or observation minus background value depending
-on the option selected in the radio button at the bottom of the window. The plotting colour
-range can be changed by clicking on the colour bar. The title of the plot gives some basic
-information about the date range and depth range shown, the extreme values, and the mean and
-rms values. It is possible to zoom in using a drag-box. You may also zoom in or out using the
-mouse wheel.
-
-The bottom part of the window controls what is visible in the plot above. There are two bars
-which select the level range plotted (for profile data). The other bars below select the date
-range shown. The bottom of the figure allows the option to plot the mean, root mean square,
-standard deviation or mean square values. As mentioned above you can choose to plot the
-observation value, the model background value or observation minus background value. The next
-group of radio buttons selects the map projection. This can either be regular latitude
-longitude grid, or north or south polar stereographic. The next group of radio buttons will
-plot bad observations, switch to salinity and plot density for profile observations. The
-rightmost group of buttons will print the plot window as a postscript, save it as png, or exit
-from dataplot.
+This is split into three parts.
+At the top there is a menu bar which contains a variety of drop down menus.
+Areas - zooms into prespecified regions;
+plot - plots the data as a timeseries or a T-S diagram if appropriate;
+Find - allows data to be searched;
+Config - sets various configuration options.
+
+The middle part is a plot of the geographical location of the observations.
+This will plot the observation value, the model background value or observation minus background value depending on
+the option selected in the radio button at the bottom of the window.
+The plotting colour range can be changed by clicking on the colour bar.
+The title of the plot gives some basic information about the date range and depth range shown,
+the extreme values, and the mean and rms values.
+It is possible to zoom in using a drag-box.
+You may also zoom in or out using the mouse wheel.
+
+The bottom part of the window controls what is visible in the plot above.
+There are two bars which select the level range plotted (for profile data).
+The other bars below select the date range shown.
+The bottom of the figure allows the option to plot the mean, root mean square, standard deviation or
+mean square values.
+As mentioned above you can choose to plot the observation value, the model background value or
+observation minus background value.
+The next group of radio buttons selects the map projection.
+This can either be regular latitude longitude grid, or north or south polar stereographic.
+The next group of radio buttons will plot bad observations, switch to salinity and
+plot density for profile observations.
+The rightmost group of buttons will print the plot window as a postscript, save it as png, or exit from dataplot.
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -1386,10 +1371,10 @@
 \includegraphics[width=9cm,angle=-90.]{Fig_OBS_dataplot_main}
 \caption{      \protect\label{fig:obsdataplotmain}
-Main window of dataplot.}
+  Main window of dataplot.}
 \end{center}     \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 
-If a profile point is clicked with the mouse button a plot of the observation and background
-values as a function of depth (\autoref{fig:obsdataplotprofile}).
+If a profile point is clicked with the mouse button a plot of the observation and background values as
+a function of depth (\autoref{fig:obsdataplotprofile}).
 
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
@@ -1398,5 +1383,5 @@
 \includegraphics[width=7cm,angle=-90.]{Fig_OBS_dataplot_prof}
 \caption{      \protect\label{fig:obsdataplotprofile}
-Profile plot from dataplot produced by right clicking on a point in the main window.}
+  Profile plot from dataplot produced by right clicking on a point in the main window.}
 \end{center}     \end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
