Changeset 11830 for NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DIA.tex

Timestamp:

2019-10-29T17:51:07+01:00 (4 years ago)

Author:

acc

Message:

Branch 2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps. Merge changes to doc from trunk r10740 through r11740

Location:

NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc

Files:

• . (modified) (3 props)
• latex (modified) (1 prop)
• latex/NEMO (modified) (2 props)
• latex/NEMO/subfiles (modified) (1 prop)
• latex/NEMO/subfiles/chap_DIA.tex (modified) (98 diffs)

NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles

@@ -1 @@
-*.aux
-*.bbl
-*.blg
-*.dvi
-*.fdb*
-*.fls
-*.idx
+*.ind
 *.ilg
-*.ind
-*.log
-*.maf
-*.mtc*
-*.out
-*.pdf
-*.toc
-_minted-*

@@ -1 @@
-*.aux
-*.bbl
-*.blg
-*.dvi
-*.fdb*
-*.fls
-*.idx
+*.ind
 *.ilg
-*.ind
-*.log
-*.maf
-*.mtc*
-*.out
-*.pdf
-*.toc
-_minted-*

NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DIA.tex

@@ -2 +2 @@
 
 \begin{document}
-% ================================================================
-% Chapter I/O & Diagnostics
-% ================================================================
+
 \chapter{Output and Diagnostics (IOM, DIA, TRD, FLO)}
 \label{chap:DIA}
 
-\minitoc
-
-\newpage
-
-% ================================================================
-%       Old Model Output 
-% ================================================================
-\section{Old model output (default)}
+%    {\em 4.0} & {\em Mirek Andrejczuk, Massimiliano Drudi} & {\em }  \\
+%    {\em }      & {\em Dorotea Iovino, Nicolas Martin} & {\em }  \\
+%    {\em 3.6} & {\em Gurvan Madec, Sebastien Masson } & {\em }  \\
+%    {\em 3.4} & {\em Gurvan Madec, Rachid Benshila, Andrew Coward } & {\em }  \\
+%    {\em }      & {\em Christian Ethe, Sebastien Masson } & {\em }  \\
+
+\thispagestyle{plain}
+
+\chaptertoc
+
+\paragraph{Changes record} ~\\
+
+{\footnotesize
+  \begin{tabularx}{\textwidth}{l||X|X}
+    Release & Author(s) & Modifications \\
+    \hline
+    {\em   4.0} & {\em ...} & {\em ...} \\
+    {\em   3.6} & {\em ...} & {\em ...} \\
+    {\em   3.4} & {\em ...} & {\em ...} \\
+    {\em <=3.4} & {\em ...} & {\em ...}
+  \end{tabularx}
+}
+
+\clearpage
+
+%% =================================================================================================
+\section{Model output}
 \label{sec:DIA_io_old}
 
@@ -25 +42 @@
 the same run performed in one step.
 It should be noted that this requires that the restart file contains two consecutive time steps for
-all the prognostic variables, and that it is saved in the same binary format as the one used by the computer that
-is to read it (in particular, 32 bits binary IEEE format must not be used for this file).
+all the prognostic variables.
 
 The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs.
-The output listing is stored in the $ocean.output$ file.
-The information is printed from within the code on the logical unit $numout$.
+The output listing is stored in the \textit{ocean.output} file.
+The information is printed from within the code on the logical unit \texttt{numout}.
 To locate these prints, use the UNIX command "\textit{grep -i numout}" in the source code directory.
 
@@ -39 +55 @@
 A complete description of the use of this I/O server is presented in the next section.
 
-By default, \key{iomput} is not defined,
-NEMO produces NetCDF with the old IOIPSL library which has been kept for compatibility and its easy installation.
-However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2,
-many diagnostic options have been added presuming the use of \key{iomput}.
-The usefulness of the default IOIPSL-based option is expected to reduce with each new release.
-If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and
-contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of
-nn\_write time-steps (namelist parameter). 
-
-%\gmcomment{                    % start of gmcomment
-
-% ================================================================
-% Diagnostics
-% ================================================================
+%\cmtgm{                    % start of gmcomment
+
+%% =================================================================================================
 \section{Standard model output (IOM)}
 \label{sec:DIA_iom}
 
-Since version 3.2, iomput is the NEMO output interface of choice.
+Since version 3.2, iomput is the \NEMO\ output interface of choice.
 It has been designed to be simple to use, flexible and efficient.
-The two main purposes of iomput are: 
+The two main purposes of iomput are:
 
 \begin{enumerate}
-\item
-  The complete and flexible control of the output files through external XML files adapted by
+\item The complete and flexible control of the output files through external XML files adapted by
   the user from standard templates.
-\item
-  To achieve high performance and scalable output through the optional distribution of
+\item To achieve high performance and scalable output through the optional distribution of
   all diagnostic output related tasks to dedicated processes.
 \end{enumerate}
 
-The first functionality allows the user to specify, without code changes or recompilation, 
+The first functionality allows the user to specify, without code changes or recompilation,
 aspects of the diagnostic output stream, such as:
 
 \begin{itemize}
-\item
-  The choice of output frequencies that can be different for each file (including real months and years).
-\item
-  The choice of file contents; includes complete flexibility over which data are written in which files
+\item The choice of output frequencies that can be different for each file (including real months and years).
+\item The choice of file contents; includes complete flexibility over which data are written in which files
   (the same data can be written in different files).
-\item
-  The possibility to split output files at a chosen frequency.
-\item
-  The possibility to extract a vertical or an horizontal subdomain.
-\item
-  The choice of the temporal operation to perform, \eg: average, accumulate, instantaneous, min, max and once.
-\item
-  Control over metadata via a large XML "database" of possible output fields.
+\item The possibility to split output files at a chosen frequency.
+\item The possibility to extract a vertical or an horizontal subdomain.
+\item The choice of the temporal operation to perform, \eg: average, accumulate, instantaneous, min, max and once.
+\item Control over metadata via a large XML "database" of possible output fields.
 \end{itemize}
 
@@ -91 +88 @@
 in a very easy way.
 All details of iomput functionalities are listed in the following subsections.
-Examples of the XML files that control the outputs can be found in: \path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml},
-\path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}. \\
+Examples of the XML files that control the outputs can be found in:
+\path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef.xml},
+\path{cfgs/SHARED/field_def_nemo-oce.xml},
+\path{cfgs/SHARED/field_def_nemo-pisces.xml},
+\path{cfgs/SHARED/field_def_nemo-ice.xml} and \path{cfgs/SHARED/domain_def_nemo.xml}. \\
 
 The second functionality targets output performance when running in parallel (\key{mpp\_mpi}).
-Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes)
+Iomput provides the possibility to specify N dedicated I/O processes (in addition to the \NEMO\ processes)
 to collect and write the outputs.
 With an appropriate choice of N by the user, the bottleneck associated with the writing of
 the output files can be greatly reduced.
 
-In version 3.6, the iom\_put interface depends on
-an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0} 
-(use of revision 618 or higher is required).
+In version 3.6, the \rou{iom\_put} interface depends on
+an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-2.5}{XIOS-2.5}
+%(use of revision 618 or higher is required).
 This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to
 create a single output file and therefore to bypass the rebuilding phase.
 Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to
-an HDF5 library that has been correctly compiled (\ie with the configure option $--$enable-parallel).
+an HDF5 library that has been correctly compiled (\ie\ with the configure option $--$enable-parallel).
 Note that the files created by iomput through XIOS are incompatible with NetCDF3.
 All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3.
 
 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers,
-where N is typically much less than the number of NEMO processors, will reduce the number of output files created.
-This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors.
+where N is typically much less than the number of \NEMO\ processors, will reduce the number of output files created.
+This can greatly reduce the post-processing burden usually associated with using large numbers of \NEMO\ processors.
 Note that for smaller configurations, the rebuilding phase can be avoided,
 even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server.
 
+%% =================================================================================================
 \subsection{XIOS: Reading and writing restart file}
 
-XIOS may be used to read single file restart produced by NEMO. Currently only the variables written to 
-file \forcode{numror} can be handled by XIOS. To activate restart reading using XIOS, set \np{ln\_xios\_read}\forcode{ = .true. }
-in \textit{namelist\_cfg}. This setting will be ignored when multiple restart files are present, and default NEMO 
-functionality will be used for reading. There is no need to change iodef.xml file to use XIOS to read 
-restart, all definitions are done within the NEMO code. For high resolution configuration, however, 
+XIOS may be used to read single file restart produced by \NEMO. Currently only the variables written to
+file \forcode{numror} can be handled by XIOS. To activate restart reading using XIOS, set \np[=.true. ]{ln_xios_read}{ln\_xios\_read}
+in \textit{namelist\_cfg}. This setting will be ignored when multiple restart files are present, and default \NEMO
+functionality will be used for reading. There is no need to change iodef.xml file to use XIOS to read
+restart, all definitions are done within the \NEMO\ code. For high resolution configuration, however,
 there may be a need to add the following line in iodef.xml (xios context):
 
@@ -129 +130 @@
 \end{xmllines}
 
-This variable sets timeout for reading. 
-
-If XIOS is to be used to read restart from file generated with an earlier NEMO version (3.6 for instance),
+This variable sets timeout for reading.
+
+If XIOS is to be used to read restart from file generated with an earlier \NEMO\ version (3.6 for instance),
 dimension \forcode{z} defined in restart file must be renamed to \forcode{nav_lev}.\\
 
-XIOS can also be used to write NEMO restart. A namelist parameter \np{nn\_wxios} is used to determine the 
-type of restart NEMO will write. If it is set to 0, default NEMO functionality will be used - each 
-processor writes its own restart file; if it is set to 1 XIOS will write restart into a single file; 
-for \np{nn\_wxios = 2} the restart will be written by XIOS into multiple files, one for each XIOS server. 
-Note, however, that \textbf{NEMO will not read restart generated by XIOS when \np{nn\_wxios = 2}}. The restart will 
-have to be rebuild before continuing the run. This option aims to reduce number of restart files generated by NEMO only, 
-and may be useful when there is a need to change number of processors used to run simulation. 
+XIOS can also be used to write \NEMO\ restart. A namelist parameter \np{nn_wxios}{nn\_wxios} is used to determine the
+type of restart \NEMO\ will write. If it is set to 0, default \NEMO\ functionality will be used - each
+processor writes its own restart file; if it is set to 1 XIOS will write restart into a single file;
+for \np[=2]{nn_wxios}{nn\_wxios} the restart will be written by XIOS into multiple files, one for each XIOS server.
+Note, however, that \textbf{\NEMO\ will not read restart generated by XIOS when \np[=2]{nn_wxios}{nn\_wxios}}. The restart will
+have to be rebuild before continuing the run. This option aims to reduce number of restart files generated by \NEMO\ only,
+and may be useful when there is a need to change number of processors used to run simulation.
 
 If an additional variable must be written to a restart file, the following steps are needed:
-\begin{description}
-   \item[step 1:] add variable name to a list of restart variables (in subroutine \rou{iom\_set\_rst\_vars,} \mdl{iom}) and 
-define correct grid for the variable (\forcode{grid_N_3D} - 3D variable, \forcode{grid_N} - 2D variable, \forcode{grid_vector} - 
+\begin{enumerate}
+\item Add variable name to a list of restart variables (in subroutine \rou{iom\_set\_rst\_vars,} \mdl{iom}) and
+define correct grid for the variable (\forcode{grid_N_3D} - 3D variable, \forcode{grid_N} - 2D variable, \forcode{grid_vector} -
 1D variable, \forcode{grid_scalar} - scalar),
-   \item[step 2:] add variable to the list of fields written by restart.  This can be done either in subroutine 
-\rou{iom\_set\_rstw\_core} (\mdl{iom}) or by calling  \rou{iom\_set\_rstw\_active} (\mdl{iom}) with the name of a variable 
-as an argument. This convention follows approach for writing restart using iom, where variables are 
+\item Add variable to the list of fields written by restart.  This can be done either in subroutine
+\rou{iom\_set\_rstw\_core} (\mdl{iom}) or by calling  \rou{iom\_set\_rstw\_active} (\mdl{iom}) with the name of a variable
+as an argument. This convention follows approach for writing restart using iom, where variables are
 written either by \rou{rst\_write} or by calling \rou{iom\_rstput} from individual routines.
-\end{description}
-
+\end{enumerate}
 
 An older versions of XIOS do not support reading functionality. It's recommended to use at least XIOS2@1451.
 
-
+%% =================================================================================================
 \subsection{XIOS: XML Inputs-Outputs Server}
 
+%% =================================================================================================
 \subsubsection{Attached or detached mode?}
 
@@ -168 +169 @@
 \xmlline|<variable id="using_server" type="bool"></variable>|
 
-The {\tt using\_server} setting determines whether or not the server will be used in \textit{attached mode}
-(as a library) [{\tt> false <}] or in \textit{detached mode}
-(as an external executable on N additional, dedicated cpus) [{\tt > true <}].
-The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications.
+The \texttt{using\_server} setting determines whether or not the server will be used in
+\textit{attached mode}
+(as a library) [\texttt{> false <}] or in \textit{detached mode}
+(as an external executable on N additional, dedicated cpus) [\texttt{ > true <}].
+The \textit{attached mode} is simpler to use but much less efficient for
+massively parallel applications.
 The type of each file can be either ''multiple\_file'' or ''one\_file''.
 
 In \textit{attached mode} and if the type of file is ''multiple\_file'',
-then each NEMO process will also act as an IO server and produce its own set of output files.
+then each \NEMO\ process will also act as an IO server and produce its own set of output files.
 Superficially, this emulates the standard behaviour in previous versions.
 However, the subdomain written out by each process does not correspond to
@@ -187 +190 @@
 write to its own set of output files.
 If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and
-write (in parallel) to a single output file. 
+write (in parallel) to a single output file.
 Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job.
 The following subsection provides a typical example but the syntax will vary in different MPP environments.
 
+%% =================================================================================================
 \subsubsection{Number of cpu used by XIOS in detached mode}
 
 The number of cores used by the XIOS is specified when launching the model.
-The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of 
-cores dedicated to NEMO.
+The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of
+cores dedicated to \NEMO.
 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but
-this is a general recommendation and not specific to NEMO.
+this is a general recommendation and not specific to \NEMO.
 It is difficult to provide precise recommendations because the optimal choice will depend on
-the particular hardware properties of the target system 
+the particular hardware properties of the target system
 (parallel filesystem performance, available memory, memory bandwidth etc.)
 and the volume and frequency of data to be created.
@@ -205 +209 @@
 \cmd|mpirun -np 62 ./nemo.exe : -np 2 ./xios_server.exe|
 
+%% =================================================================================================
 \subsubsection{Control of XIOS: the context in iodef.xml}
 
-As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml.
+As well as the \texttt{using\_server} flag, other controls on the use of XIOS are set in
+the XIOS context in \textit{iodef.xml}.
 See the XML basics section below for more details on XML syntax and rules.
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|lXl|}
     \hline
@@ -220 +225 @@
     \hline
     buffer\_size                                                            &
-    buffer size used by XIOS to send data from NEMO to XIOS.
+    buffer size used by XIOS to send data from \NEMO\ to XIOS.
     Larger is more efficient.
     Note that needed/used buffer sizes are summarized at the end of the job &
@@ -226 +231 @@
     \hline
     buffer\_server\_factor\_size                                            &
-    ratio between NEMO and XIOS buffer size.
+    ratio between \NEMO\ and XIOS buffer size.
     Should be 2.                                                            &
     2        \\
@@ -243 +248 @@
     \hline
     oasis\_codes\_id                                                        &
-    when using oasis, define the identifier of NEMO in the namcouple.
+    when using oasis, define the identifier of \NEMO\ in the namcouple.
     Note that the identifier of XIOS is xios.x                              &
     oceanx   \\
@@ -250 +255 @@
 \end{table}
 
+%% =================================================================================================
 \subsection{Practical issues}
 
+%% =================================================================================================
 \subsubsection{Installation}
 
-As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO.
+As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with \NEMO.
 See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance.
-NEMO will need to link to the compiled XIOS library.
-The \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS}
-{XIOS with NEMO} guide provides an example illustration of how this can be achieved.
-
+\NEMO\ will need to link to the compiled XIOS library.
+The \href{https://forge.ipsl.jussieu.fr/nemo/chrome/site/doc/NEMO/guide/html/install.html#extract-and-install-xios}
+{Extract and install XIOS} guide provides an example illustration of how this can be achieved.
+
+%% =================================================================================================
 \subsubsection{Add your own outputs}
 
@@ -268 +276 @@
 
 \begin{enumerate}
-\item[1.]
-  in NEMO code, add a \forcode{CALL iom\_put( 'identifier', array )} where you want to output a 2D or 3D array.
-\item[2.]
-  If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in
+\item in \NEMO\ code, add a \forcode{CALL iom_put( 'identifier', array )} where you want to output a 2D or 3D array.
+\item If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in
   the upper part of your module.
-\item[3.]
-  in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code
+\item in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code
   (see subsequent sections for a details of the XML syntax and rules).
   For example:
-
 \begin{xmllines}
 <field_definition>
    <field_group id="grid_T" grid_ref="grid_T_3D"> <!-- T grid -->
    ...
-      <field id="identifier" long_name="blabla" ... />   
+      <field id="identifier" long_name="blabla" ... />
       ...
-</field_definition> 
-\end{xmllines}
-
+</field_definition>
+\end{xmllines}
 Note your definition must be added to the field\_group whose reference grid is consistent with the size of
 the array passed to iomput.
@@ -293 +296 @@
 (iom\_set\_domain\_attr and iom\_set\_axis\_attr in \mdl{iom}) or defined in the domain\_def.xml file.
 \eg:
-
 \begin{xmllines}
 <grid id="grid_T_3D" domain_ref="grid_T" axis_ref="deptht"/>
 \end{xmllines}
-
-Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step,
+Note, if your array is computed within the surface module each \np{nn_fsbc}{nn\_fsbc} time\_step,
 add the field definition within the field\_group defined with the id "SBC":
 \xmlcode{<field_group id="SBC" ...>} which has been defined with the correct frequency of operations
 (iom\_set\_field\_attr in \mdl{iom})
-\item[4.]
-  add your field in one of the output files defined in iodef.xml
+\item add your field in one of the output files defined in iodef.xml
   (again see subsequent sections for syntax and rules)
-
-\begin{xmllines}
-<file id="file1" .../>   
+\begin{xmllines}
+<file id="file1" .../>
 ...
-   <field field_ref="identifier" />   
+   <field field_ref="identifier" />
    ...
-</file>   
-\end{xmllines}
-
+</file>
+\end{xmllines}
 \end{enumerate}
 
+%% =================================================================================================
 \subsection{XML fundamentals}
 
+%% =================================================================================================
 \subsubsection{ XML basic rules}
 
@@ -327 +327 @@
 See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details.
 
-\subsubsection{Structure of the XML file used in NEMO}
+%% =================================================================================================
+\subsubsection{Structure of the XML file used in \NEMO}
 
 The XML file used in XIOS is structured by 7 families of tags:
@@ -334 +335 @@
 
 \begin{table}
-  \scriptsize
   \begin{tabular*}{\textwidth}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|}
     \hline
@@ -366 +366 @@
 
 \begin{table}
-  \scriptsize
   \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|}
     \hline
@@ -376 +375 @@
                                                                                                      \xmlcode{<context id="xios" ... >}   \\
     \hline
-    context nemo    &   context containing IO information for NEMO (mother grid when using AGRIF)  & 
+    context nemo    &   context containing IO information for \NEMO\ (mother grid when using AGRIF)  &
                                                                                                      \xmlcode{<context id="nemo" ... >}   \\
     \hline
-    context 1\_nemo &   context containing IO information for NEMO child grid 1 (when using AGRIF) & 
+    context 1\_nemo &   context containing IO information for \NEMO\ child grid 1 (when using AGRIF) &
                                                                                                      \xmlcode{<context id="1_nemo" ... >} \\
     \hline
-    context n\_nemo &   context containing IO information for NEMO child grid n (when using AGRIF) & 
+    context n\_nemo &   context containing IO information for \NEMO\ child grid n (when using AGRIF) &
                                                                                                      \xmlcode{<context id="n_nemo" ... >} \\
     \hline
@@ -391 +390 @@
 
 \begin{table}
-  \scriptsize
   \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|}
     \hline
@@ -407 +405 @@
 \end{table}
 
-\noindent Each context tag related to NEMO (mother or child grids) is divided into 5 parts 
+\noindent Each context tag related to \NEMO\ (mother or child grids) is divided into 5 parts
 (that can be defined in any order):
 
 \begin{table}
-  \scriptsize
   \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|}
     \hline
@@ -436 +433 @@
 \end{table}
 
+%% =================================================================================================
 \subsubsection{Nesting XML files}
 
@@ -441 +439 @@
 The inclusion of XML files into the main XML file can be done through the attribute src:
 \xmlline|<context src="./nemo_def.xml" />|
- 
-\noindent In NEMO, by default, the field and domain definition is done in 2 separate files:
-\path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml} that
+
+\noindent In \NEMO, by default, the field definition is done in 3 separate files (
+\path{cfgs/SHARED/field_def_nemo-oce.xml},
+\path{cfgs/SHARED/field_def_nemo-pisces.xml} and
+\path{cfgs/SHARED/field_def_nemo-ice.xml} ) and the  domain definition is done in another file ( \path{cfgs/SHARED/domain_def_nemo.xml} )
+that
 are included in the main iodef.xml file through the following commands:
 \begin{xmllines}
-<field_definition src="./field_def.xml" />
-<domain_definition src="./domain_def.xml" />
-\end{xmllines}
-
+<context id="nemo" src="./context_nemo.xml"/>
+\end{xmllines}
+
+%% =================================================================================================
 \subsubsection{Use of inheritance}
 
@@ -462 +463 @@
 \begin{xmllines}
 <field_definition operation="average" >
-   <field id="sst"                    />   <!-- averaged      sst --> 
-   <field id="sss" operation="instant"/>   <!-- instantaneous sss --> 
-</field_definition> 
+   <field id="sst"                    />   <!-- averaged      sst -->
+   <field id="sss" operation="instant"/>   <!-- instantaneous sss -->
+</field_definition>
 \end{xmllines}
 
@@ -481 +482 @@
 </field_definition>
 <file_definition>
-   <file id="myfile" output_freq="1d" />   
+   <file id="myfile" output_freq="1d" />
       <field field_ref="sst"                            />  <!-- default def -->
       <field field_ref="sss" long_name="my description" />  <!-- overwrite   -->
    </file>
-</file_definition> 
+</file_definition>
 \end{xmllines}
 
 Inherit (and overwrite, if needed) the attributes of a tag you are refering to.
 
+%% =================================================================================================
 \subsubsection{Use of groups}
 
@@ -508 +510 @@
 
 Secondly, the group can be used to replace a list of elements.
-Several examples of groups of fields are proposed at the end of the file \path{CONFIG/SHARED/field_def.xml}.
+Several examples of groups of fields are proposed at the end of the XML field files (
+\path{cfgs/SHARED/field_def_nemo-oce.xml},
+\path{cfgs/SHARED/field_def_nemo-pisces.xml} and
+\path{cfgs/SHARED/field_def_nemo-ice.xml} ) .
 For example, a short list of the usual variables related to the U grid:
 
@@ -514 +519 @@
 <field_group id="groupU" >
    <field field_ref="uoce"  />
-   <field field_ref="suoce" />
+   <field field_ref="ssu" />
    <field field_ref="utau"  />
 </field_group>
@@ -525 +530 @@
    <field_group group_ref="groupU" />
    <field field_ref="uocetr_eff"   />  <!-- add another field -->
-</file>   
-\end{xmllines}
-
+</file>
+\end{xmllines}
+
+%% =================================================================================================
 \subsection{Detailed functionalities}
 
@@ -533 +539 @@
 the new functionalities offered by the XML interface of XIOS.
 
+%% =================================================================================================
 \subsubsection{Define horizontal subdomains}
 
 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of
 the tag family domain.
-It must therefore be done in the domain part of the XML file. 
-For example, in \path{CONFIG/SHARED/domain_def.xml}, we provide the following example of a definition of 
+It must therefore be done in the domain part of the XML file.
+For example, in \path{cfgs/SHARED/domain_def.xml}, we provide the following example of a definition of
 a 5 by 5 box with the bottom left corner at point (10,10).
 
 \begin{xmllines}
-<domain_group id="grid_T">
-   <domain id="myzoom" zoom_ibegin="10" zoom_jbegin="10" zoom_ni="5" zoom_nj="5" />
+<domain id="myzoomT" domain_ref="grid_T">
+   <zoom_domain ibegin="10" jbegin="10" ni="5" nj="5" />
 \end{xmllines}
 
@@ -551 +558 @@
 \begin{xmllines}
 <file id="myfile_vzoom" output_freq="1d" >
-   <field field_ref="toce" domain_ref="myzoom"/>
+   <field field_ref="toce" domain_ref="myzoomT"/>
 </file>
 \end{xmllines}
 
-Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 
+Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain.
 The Equatorial section, the TAO, RAMA and PIRATA moorings are already registered in the code and
 can therefore be outputted without taking care of their (i,j) position in the grid.
@@ -568 +575 @@
 \end{xmllines}
 
-Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if 
-you use the ''multiple\_file'' type for your output files, 
-you will endup with several files you will need to rebuild using unprovided tools (like ncpdq and ncrcat, 
+Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if
+you use the ''multiple\_file'' type for your output files,
+you will endup with several files you will need to rebuild using unprovided tools (like ncpdq and ncrcat,
 \href{http://nco.sourceforge.net/nco.html#Concatenation}{see nco manual}).
 We are therefore advising to use the ''one\_file'' type in this case.
 
+%% =================================================================================================
 \subsubsection{Define vertical zooms}
 
-Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis.
+Vertical zooms are defined through the attributs zoom\_begin and zoom\_n of the tag family axis.
 It must therefore be done in the axis part of the XML file.
-For example, in \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml}, we provide the following example:
-
-\begin{xmllines}
-<axis_group id="deptht" long_name="Vertical T levels" unit="m" positive="down" >
-   <axis id="deptht" />
-   <axis id="deptht_myzoom" zoom_begin="1" zoom_end="10" />
+For example, in \path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef_demo.xml}, we provide the following example:
+
+\begin{xmllines}
+<axis_definition>
+   <axis id="deptht" long_name="Vertical T levels" unit="m" positive="down" />
+   <axis id="deptht_zoom" azix_ref="deptht" >
+      <zoom_axis zoom_begin="1" zoom_n="10" />
+   </axis>
 \end{xmllines}
 
@@ -595 +605 @@
 \end{xmllines}
 
+%% =================================================================================================
 \subsubsection{Control of the output file names}
 
@@ -601 +612 @@
 
 \begin{xmllines}
-<file_group id="1d" output_freq="1d" name="myfile_1d" > 
+<file_group id="1d" output_freq="1d" name="myfile_1d" >
    <file id="myfileA" name_suffix="_AAA" > <!-- will create file "myfile_1d_AAA"  -->
       ...
@@ -620 +631 @@
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|lX|}
     \hline
@@ -656 +666 @@
 \end{table}
 
-\noindent For example, 
+\noindent For example,
 \xmlline|<file id="myfile_hzoom" name="myfile_@expname@_@startdate@_freq@freq@" output_freq="1d" >|
 
@@ -668 +678 @@
 \noindent will give the following file name radical: \ifile{myfile\_ORCA2\_19891231\_freq1d}
 
-\subsubsection{Other controls of the XML attributes from NEMO}
-
-The values of some attributes are defined by subroutine calls within NEMO 
+%% =================================================================================================
+\subsubsection{Other controls of the XML attributes from \NEMO}
+
+The values of some attributes are defined by subroutine calls within \NEMO
 (calls to iom\_set\_domain\_attr, iom\_set\_axis\_attr and iom\_set\_field\_attr in \mdl{iom}).
 Any definition given in the XML file will be overwritten.
@@ -681 +692 @@
 
 \begin{table}
-  \scriptsize
-  \begin{tabularx}{\textwidth}{|X|c|c|c|}
+  \begin{tabular}{|l|c|c|}
     \hline
     tag ids affected by automatic definition of some of their attributes &
     name attribute                                                       &
-    attribute value                      \\
+    attribute value                                                      \\
     \hline
     \hline
     field\_definition                                                    &
     freq\_op                                                             &
-    \np{rn\_rdt}                         \\
+    \np{rn_rdt}{rn\_rdt}                                                         \\
     \hline
     SBC                                                                  &
     freq\_op                                                             &
-    \np{rn\_rdt} $\times$ \np{nn\_fsbc}  \\
+    \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_fsbc}{nn\_fsbc}                                  \\
     \hline
     ptrc\_T                                                              &
     freq\_op                                                             &
-    \np{rn\_rdt} $\times$ \np{nn\_dttrc} \\
+    \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_dttrc}{nn\_dttrc}                                 \\
     \hline
     diad\_T                                                              &
     freq\_op                                                             &
-    \np{rn\_rdt} $\times$ \np{nn\_dttrc} \\
+    \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_dttrc}{nn\_dttrc}                                 \\
     \hline
     EqT, EqU, EqW                                                        &
     jbegin, ni,                                                          &
-    according to the grid                \\
-    &
+    according to the grid                                                \\
+                                                                         &
     name\_suffix                                                         &
-    \\
+                                                                         \\
     \hline
     TAO, RAMA and PIRATA moorings                                        &
     zoom\_ibegin, zoom\_jbegin,                                          &
-    according to the grid                \\
-    &
+    according to the grid                                                \\
+                                                                         &
     name\_suffix                                                         &
-    \\
-    \hline
-  \end{tabularx}
+                                                                         \\
+    \hline
+  \end{tabular}
 \end{table}
 
+%% =================================================================================================
 \subsubsection{Advanced use of XIOS functionalities}
 
+%% =================================================================================================
 \subsection{XML reference tables}
-\label{subsec:IOM_xmlref}
+\label{subsec:DIA_IOM_xmlref}
 
 \begin{enumerate}
-\item
-  Simple computation: directly define the computation when refering to the variable in the file definition.
+\item Simple computation: directly define the computation when refering to the variable in the file definition.
 
 \begin{xmllines}
@@ -737 +748 @@
 \end{xmllines}
 
-\item
-  Simple computation: define a new variable and use it in the file definition.
+\item Simple computation: define a new variable and use it in the file definition.
 
 in field\_definition:
@@ -755 +765 @@
 sst2 won't be evaluated.
 
-\item
-  Change of variable precision:
+\item Change of variable precision:
 
 \begin{xmllines}
@@ -765 +774 @@
 \end{xmllines}
 
-Note that, then the code is crashing, writting real4 variables forces a numerical convection from 
+Note that, then the code is crashing, writting real4 variables forces a numerical conversion from
 real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files.
 Forcing double precision outputs with prec="8" (for example in the field\_definition) will avoid this problem.
 
-\item
-  add user defined attributes:
-
-\begin{xmllines}
-<file_group id="1d" output_freq="1d" output_level="10" enabled=".true."> <!-- 1d files --> 
+\item add user defined attributes:
+
+\begin{xmllines}
+<file_group id="1d" output_freq="1d" output_level="10" enabled=".true."> <!-- 1d files -->
    <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" >
       <field field_ref="sst" name="tos" >
@@ -782 +790 @@
       <variable id="my_global_attribute" type="string" > blabla_global </variable>
    </file>
-</file_group> 
-\end{xmllines}
-
-\item
-  use of the ``@'' function: example 1, weighted temporal average
+</file_group>
+\end{xmllines}
+
+\item use of the ``@'' function: example 1, weighted temporal average
 
  - define a new variable in field\_definition
@@ -797 +804 @@
 
 \begin{xmllines}
-<file_group id="5d" output_freq="5d"  output_level="10" enabled=".true." >  <!-- 5d files -->  
+<file_group id="5d" output_freq="5d"  output_level="10" enabled=".true." >  <!-- 5d files -->
    <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" >
       <field field_ref="toce" operation="instant" freq_op="5d" > @toce_e3t / @e3t </field>
    </file>
-</file_group> 
+</file_group>
 \end{xmllines}
 
@@ -814 +821 @@
 Note that in this case, freq\_op must be equal to the file output\_freq.
 
-\item
-  use of the ``@'' function: example 2, monthly SSH standard deviation
+\item use of the ``@'' function: example 2, monthly SSH standard deviation
 
  - define a new variable in field\_definition
@@ -826 +832 @@
 
 \begin{xmllines}
-<file_group id="1m" output_freq="1m"  output_level="10" enabled=".true." >  <!-- 1m files -->  
+<file_group id="1m" output_freq="1m"  output_level="10" enabled=".true." >  <!-- 1m files -->
    <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" >
-      <field field_ref="ssh" name="sshstd" long_name="sea_surface_temperature_standard_deviation" 
+      <field field_ref="ssh" name="sshstd" long_name="sea_surface_temperature_standard_deviation"
       operation="instant" freq_op="1m" >
          sqrt( @ssh2 - @ssh * @ssh )
       </field>
    </file>
-</file_group> 
+</file_group>
 \end{xmllines}
 
@@ -840 +846 @@
 here we use the default, average.
 So, in the above case, @ssh2 will do the monthly mean of ssh*ssh.
-Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'': 
+Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'':
 here the temporal average is alreday done by the ``@'' function so we just use instant.
 field\_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field.
 Note that in this case, freq\_op must be equal to the file output\_freq.
 
-\item
-  use of the ``@'' function: example 3, monthly average of SST diurnal cycle
+\item use of the ``@'' function: example 3, monthly average of SST diurnal cycle
 
  - define 2 new variables in field\_definition
@@ -858 +863 @@
 
 \begin{xmllines}
-<file_group id="1m" output_freq="1m"  output_level="10" enabled=".true." >  <!-- 1m files -->  
+<file_group id="1m" output_freq="1m"  output_level="10" enabled=".true." >  <!-- 1m files -->
    <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" >
       <field field_ref="sst" name="sstdcy" long_name="amplitude of sst diurnal cycle" operation="average" freq_op="1d" >
@@ -864 +869 @@
       </field>
    </file>
-</file_group> 
+</file_group>
 \end{xmllines}
 
@@ -877 +882 @@
 field\_ref="sst" means that attributes not explicitely defined, are inherited from sst field.
 
+%% =================================================================================================
 \subsubsection{Tag list per family}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|l|X|}
     \hline
@@ -903 +908 @@
     \hline
   \end{tabularx}
-  \caption{Context tags}
+  \caption{XIOS: context tags}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|l|}
     \hline
@@ -938 +942 @@
     \hline
   \end{tabularx}
-  \caption{Field tags ("\tt{field\_*}")}
+  \caption{XIOS: field tags ("\texttt{field\_*}")}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|l|}
     \hline
@@ -974 +977 @@
     \hline
   \end{tabularx}
-  \caption{File tags ("\tt{file\_*}")}
+  \caption{XIOS: file tags ("\texttt{file\_*}")}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|X|}
     \hline
@@ -1007 +1009 @@
     \hline
   \end{tabularx}
-  \caption{Axis tags ("\tt{axis\_*}")}
+  \caption{XIOS: axis tags ("\texttt{axis\_*}")}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|X|}
     \hline
@@ -1040 +1041 @@
     \hline
   \end{tabularx}
-  \caption{Domain tags ("\tt{domain\_*)}"}
+  \caption{XIOS: domain tags ("\texttt{domain\_*)}"}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|X|}
     \hline
@@ -1073 +1073 @@
     \hline
   \end{tabularx}
-  \caption{Grid tags ("\tt{grid\_*}")}
+  \caption{XIOS: grid tags ("\texttt{grid\_*}")}
 \end{table}
 
+%% =================================================================================================
 \subsubsection{Attributes list per family}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|l|l|}
     \hline
@@ -1114 +1114 @@
     \hline
   \end{tabularx}
-  \caption{Reference attributes ("\tt{*\_ref}")}
+  \caption{XIOS: reference attributes ("\texttt{*\_ref}")}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|l|l|}
     \hline
@@ -1150 +1149 @@
     \hline
   \end{tabularx}
-  \caption{Domain attributes ("\tt{zoom\_*}")}
+  \caption{XIOS: domain attributes ("\texttt{zoom\_*}")}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|l|l|}
     \hline
@@ -1205 +1203 @@
     \hline
   \end{tabularx}
-  \caption{File attributes}
+  \caption{XIOS: file attributes}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|l|l|}
     \hline
@@ -1254 +1251 @@
     \hline
   \end{tabularx}
-  \caption{Field attributes}
+  \caption{XIOS: field attributes}
 \end{table}
 
 \begin{table}
-  \scriptsize
   \begin{tabularx}{\textwidth}{|l|X|X|X|}
     \hline
@@ -1313 +1309 @@
     \hline
   \end{tabularx}
-  \caption{Miscellaneous attributes}
+  \caption{XIOS: miscellaneous attributes}
 \end{table}
 
+%% =================================================================================================
 \subsection{CF metadata standard compliance}
 
-Output from the XIOS-1.0 IO server is compliant with 
+Output from the XIOS IO server is compliant with
 \href{http://cfconventions.org/Data/cf-conventions/cf-conventions-1.5/build/cf-conventions.html}{version 1.5} of
-the CF metadata standard. 
+the CF metadata standard.
 Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of
-section \autoref{subsec:IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard.
+section \autoref{subsec:DIA_IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard.
 
 Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by
-the namelist parameter \np{ln\_cfmeta} in the \ngn{namrun} namelist.
+the namelist parameter \np{ln_cfmeta}{ln\_cfmeta} in the \nam{run}{run} namelist.
 This must be set to true if these metadata are to be included in the output files.
 
-
-% ================================================================
-%       NetCDF4 support
-% ================================================================
-\section{NetCDF4 support (\protect\key{netcdf4})}
+%% =================================================================================================
+\section[NetCDF4 support (\texttt{\textbf{key\_netcdf4}})]{NetCDF4 support (\protect\key{netcdf4})}
 \label{sec:DIA_nc4}
 
@@ -1340 +1334 @@
 Chunking and compression can lead to significant reductions in file sizes for a small runtime overhead.
 For a fuller discussion on chunking and other performance issues the reader is referred to
-the NetCDF4 documentation found \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}.
+the NetCDF4 documentation found \href{https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_perf_chunking.html}{here}.
 
 The new features are only available when the code has been linked with a NetCDF4 library
@@ -1346 +1340 @@
 Datasets created with chunking and compression are not backwards compatible with NetCDF3 "classic" format but
 most analysis codes can be relinked simply with the new libraries and will then read both NetCDF3 and NetCDF4 files.
-NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by
-setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} namelist:
-
-%------------------------------------------namnc4----------------------------------------------------
-
-\nlst{namnc4}
-%-------------------------------------------------------------------------------------------------------------
+\NEMO\ executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by
+setting the \np{ln_nc4zip}{ln\_nc4zip} logical to false in the \nam{nc4}{nc4} namelist:
+
+\begin{listing}
+  \nlst{namnc4}
+  \caption{\forcode{&namnc4}}
+  \label{lst:namnc4}
+\end{listing}
 
 If \key{netcdf4} has not been defined, these namelist parameters are not read.
-In this case, \np{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined.
+In this case, \np{ln_nc4zip}{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined.
 These functions will not be used but need to be included so that compilation is possible with NetCDF3 libraries.
 
@@ -1389 +1384 @@
 \end{forlines}
 
-\noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\tt 46x38x1} respectively in
-the mono-processor case (\ie global domain of {\small\tt 182x149x31}).
-An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in 
-table \autoref{tab:NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with
+\noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\texttt 46x38x1} respectively in
+the mono-processor case (\ie\ global domain of {\small\texttt 182x149x31}).
+An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in
+table \autoref{tab:DIA_NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with
 a 4x2 mpi partitioning.
 Note the variation in the compression ratio achieved which reflects chiefly the dry to wet volume ratio of
 each processing region.
 
-%------------------------------------------TABLE----------------------------------------------------
 \begin{table}
-  \scriptsize
   \centering
   \begin{tabular}{lrrr}
@@ -1431 +1424 @@
     ORCA2\_2d\_grid\_W\_0007.nc & 4416    & 1368     & 70\%      \\
   \end{tabular}
-  \caption{
-    \protect\label{tab:NC4}
-    Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression
-  }
+  \caption{Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression}
+  \label{tab:DIA_NC4}
 \end{table}
-%----------------------------------------------------------------------------------------------------
 
 When \key{iomput} is activated with \key{netcdf4} chunking and compression parameters for fields produced via
-\np{iom\_put} calls are set via an equivalent and identically named namelist to \textit{namnc4} in
-\np{xmlio\_server.def}.
-Typically this namelist serves the mean files whilst the \ngn{ namnc4} in the main namelist file continues to
+\rou{iom\_put} calls are set via an equivalent and identically named namelist to \nam{nc4}{nc4} in
+\textit{xmlio\_server.def}.
+Typically this namelist serves the mean files whilst the \nam{nc4}{nc4} in the main namelist file continues to
 serve the restart files.
 This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of
 the individual files produced by the io\_server processes may be different to those produced by
 the invidual processing regions and different chunking choices may be desired.
- 
-% -------------------------------------------------------------------------------------------------------------
-%       Tracer/Dynamics Trends
-% -------------------------------------------------------------------------------------------------------------
-\section{Tracer/Dynamics trends  (\protect\ngn{namtrd})}
+
+%% =================================================================================================
+\section[Tracer/Dynamics trends (\forcode{&namtrd})]{Tracer/Dynamics trends (\protect\nam{trd}{trd})}
 \label{sec:DIA_trd}
 
-%------------------------------------------namtrd----------------------------------------------------
-
-\nlst{namtrd} 
-%-------------------------------------------------------------------------------------------------------------
+\begin{listing}
+  \nlst{namtrd}
+  \caption{\forcode{&namtrd}}
+  \label{lst:namtrd}
+\end{listing}
 
 Each trend of the dynamics and/or temperature and salinity time evolution equations can be send to
 \mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation
-(\ie at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines).
-This capability is controlled by options offered in \ngn{namtrd} namelist.
-Note that the output are done with xIOS, and therefore the \key{IOM} is required.
-
-What is done depends on the \ngn{namtrd} logical set to \forcode{.true.}:
+(\ie\ at the end of each \textit{dyn....F90} and/or \textit{tra....F90} routines).
+This capability is controlled by options offered in \nam{trd}{trd} namelist.
+Note that the output are done with XIOS, and therefore the \key{iomput} is required.
+
+What is done depends on the \nam{trd}{trd} logical set to \forcode{.true.}:
 
 \begin{description}
-\item[\np{ln\_glo\_trd}]:
-  at each \np{nn\_trd} time-step a check of the basin averaged properties of
+\item [{\np{ln_glo_trd}{ln\_glo\_trd}}]: at each \np{nn_trd}{nn\_trd} time-step a check of the basin averaged properties of
   the momentum and tracer equations is performed.
   This also includes a check of $T^2$, $S^2$, $\tfrac{1}{2} (u^2+v2)$,
   and potential energy time evolution equations properties;
-\item[\np{ln\_dyn\_trd}]:
-  each 3D trend of the evolution of the two momentum components is output;
-\item[\np{ln\_dyn\_mxl}]:
-  each 3D trend of the evolution of the two momentum components averaged over the mixed layer is output;
-\item[\np{ln\_vor\_trd}]:
-  a vertical summation of the moment tendencies is performed,
+\item [{\np{ln_dyn_trd}{ln\_dyn\_trd}}]: each 3D trend of the evolution of the two momentum components is output;
+\item [{\np{ln_dyn_mxl}{ln\_dyn\_mxl}}]: each 3D trend of the evolution of the two momentum components averaged over the mixed layer is output;
+\item [{\np{ln_vor_trd}{ln\_vor\_trd}}]: a vertical summation of the moment tendencies is performed,
   then the curl is computed to obtain the barotropic vorticity tendencies which are output;
-\item[\np{ln\_KE\_trd}] :
-  each 3D trend of the Kinetic Energy equation is output;
-\item[\np{ln\_tra\_trd}]:
-  each 3D trend of the evolution of temperature and salinity is output;
-\item[\np{ln\_tra\_mxl}]:
-  each 2D trend of the evolution of temperature and salinity averaged over the mixed layer is output;
+\item [{\np{ln_KE_trd}{ln\_KE\_trd}}]  : each 3D trend of the Kinetic Energy equation is output;
+\item [{\np{ln_tra_trd}{ln\_tra\_trd}}]: each 3D trend of the evolution of temperature and salinity is output;
+\item [{\np{ln_tra_mxl}{ln\_tra\_mxl}}]: each 2D trend of the evolution of temperature and salinity averaged over the mixed layer is output;
 \end{description}
 
-Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via 
-the \key{trdtrc} and \key{trdmld\_trc} CPP keys.
+Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via
+the \key{trdtrc} and \key{trdmxl\_trc} CPP keys.
 
 \textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested.
-In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are not working,
-and none of the options have been tested with variable volume (\ie \key{vvl} defined).
-
-% -------------------------------------------------------------------------------------------------------------
-%       On-line Floats trajectories
-% -------------------------------------------------------------------------------------------------------------
-\section{FLO: On-Line Floats trajectories (\protect\key{floats})}
-\label{sec:FLO}
-%--------------------------------------------namflo-------------------------------------------------------
-
-\nlst{namflo} 
-%--------------------------------------------------------------------------------------------------------------
+In particular, options associated with \np{ln_dyn_mxl}{ln\_dyn\_mxl}, \np{ln_vor_trd}{ln\_vor\_trd}, and \np{ln_tra_mxl}{ln\_tra\_mxl} are not working,
+and none of the options have been tested with variable volume (\ie\ \np[=.true.]{ln_linssh}{ln\_linssh}).
+
+%% =================================================================================================
+\section[FLO: On-Line Floats trajectories (\texttt{\textbf{key\_floats}})]{FLO: On-Line Floats trajectories (\protect\key{floats})}
+\label{sec:DIA_FLO}
+
+\begin{listing}
+  \nlst{namflo}
+  \caption{\forcode{&namflo}}
+  \label{lst:namflo}
+\end{listing}
 
 The on-line computation of floats advected either by the three dimensional velocity field or constraint to
 remain at a given depth ($w = 0$ in the computation) have been introduced in the system during the CLIPPER project.
-Options are defined by \ngn{namflo} namelis variables.
-The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option),
-or on a $4^th$ Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}).
-Note that the \cite{Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which
+Options are defined by \nam{flo}{flo} namelist variables.
+The algorithm used is based either on the work of \cite{blanke.raynaud_JPO97} (default option),
+or on a $4^th$ Runge-Hutta algorithm (\np[=.true.]{ln_flork4}{ln\_flork4}).
+Note that the \cite{blanke.raynaud_JPO97} algorithm have the advantage of providing trajectories which
 are consistent with the numeric of the code, so that the trajectories never intercept the bathymetry.
 
+%% =================================================================================================
 \subsubsection{Input data: initial coordinates}
 
 Initial coordinates can be given with Ariane Tools convention
-(IJK coordinates, (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude.
-
-In case of Ariane convention, input filename is \np{init\_float\_ariane}.
+(IJK coordinates, (\np[=.true.]{ln_ariane}{ln\_ariane}) ) or with longitude and latitude.
+
+In case of Ariane convention, input filename is \textit{init\_float\_ariane}.
 Its format is: \\
-{\scriptsize \texttt{I J K nisobfl itrash itrash}}
+{ \texttt{I J K nisobfl itrash}}
 
 \noindent with:
@@ -1525 +1508 @@
  - I,J,K  : indexes of initial position
 
- - nisobfl: 0 for an isobar float, 1 for a float following the w velocity  
+ - nisobfl: 0 for an isobar float, 1 for a float following the w velocity
 
  - itrash : set to zero; it is a dummy variable to respect Ariane Tools convention
@@ -1531 +1514 @@
 \noindent Example: \\
 \noindent
-{\scriptsize
+{
   \texttt{
     100.00000  90.00000  -1.50000 1.00000   0.00000   \\
@@ -1542 +1525 @@
 In the other case (longitude and latitude), input filename is init\_float.
 Its format is: \\
-{\scriptsize \texttt{Long Lat depth nisobfl ngrpfl itrash}}
+{ \texttt{Long Lat depth nisobfl ngrpfl itrash}}
 
 \noindent with:
@@ -1556 +1539 @@
 \noindent Example: \\
 \noindent
-{\scriptsize
+{
   \texttt{
     20.0 0.0 0.0 0 1 1    \\
@@ -1565 +1548 @@
 } \\
 
-\np{jpnfl} is the total number of floats during the run.
-When initial positions are read in a restart file (\np{ln\_rstflo}\forcode{ = .true.} ),
-\np{jpnflnewflo} can be added in the initialization file.
-
+\np{jpnfl}{jpnfl} is the total number of floats during the run.
+When initial positions are read in a restart file (\np[=.true.]{ln_rstflo}{ln\_rstflo} ),
+\np{jpnflnewflo}{jpnflnewflo} can be added in the initialization file.
+
+%% =================================================================================================
 \subsubsection{Output data}
 
-\np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} is the frequency of
+\np{nn_writefl}{nn\_writefl} is the frequency of writing in float output file and \np{nn_stockfl}{nn\_stockfl} is the frequency of
 creation of the float restart file.
 
-Output data can be written in ascii files (\np{ln\_flo\_ascii}\forcode{ = .true.}).
+Output data can be written in ascii files (\np[=.true.]{ln_flo_ascii}{ln\_flo\_ascii}).
 In that case, output filename is trajec\_float.
 
-Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii}\forcode{ = .false.}).
-There are 2 possibilities:
-
-- if (\key{iomput}) is used, outputs are selected in  iodef.xml.
+Another possiblity of writing format is Netcdf (\np[=.false.]{ln_flo_ascii}{ln\_flo\_ascii}) with
+\key{iomput} and outputs selected in iodef.xml.
 Here it is an example of specification to put in files description section:
 
@@ -1597 +1579 @@
 \end{xmllines}
 
- -  if (\key{iomput}) is not used, a file called \ifile{trajec\_float} will be created by IOIPSL library.
-
- See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing the off-line use of
- this marvellous diagnostic tool.
-
-% -------------------------------------------------------------------------------------------------------------
-%       Harmonic analysis of tidal constituents
-% -------------------------------------------------------------------------------------------------------------
-\section{Harmonic analysis of tidal constituents (\protect\key{diaharm}) }
+%% =================================================================================================
+\section[Harmonic analysis of tidal constituents (\texttt{\textbf{key\_diaharm}})]{Harmonic analysis of tidal constituents (\protect\key{diaharm})}
 \label{sec:DIA_diag_harm}
 
-%------------------------------------------namdia_harm----------------------------------------------------
-%
-\nlst{nam_diaharm}
-%----------------------------------------------------------------------------------------------------------
+\begin{listing}
+  \nlst{nam_diaharm}
+  \caption{\forcode{&nam_diaharm}}
+  \label{lst:nam_diaharm}
+\end{listing}
 
 A module is available to compute the amplitude and phase of tidal waves.
 This on-line Harmonic analysis is actived with \key{diaharm}.
 
-Some parameters are available in namelist \ngn{namdia\_harm}:
-
- - \np{nit000\_han} is the first time step used for harmonic analysis
-
- - \np{nitend\_han} is the  last time step used for harmonic analysis
-
- - \np{nstep\_han}  is the  time step frequency for harmonic analysis
-
- - \np{nb\_ana}     is the number of harmonics to analyse
-
- - \np{tname}       is an array with names of tidal constituents to analyse
-
- \np{nit000\_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation.
+Some parameters are available in namelist \nam{_diaharm}{\_diaharm}:
+
+ - \np{nit000_han}{nit000\_han} is the first time step used for harmonic analysis
+
+ - \np{nitend_han}{nitend\_han} is the  last time step used for harmonic analysis
+
+ - \np{nstep_han}{nstep\_han}  is the  time step frequency for harmonic analysis
+
+% - \np{nb_ana}{nb\_ana}     is the number of harmonics to analyse
+
+ - \np{tname}{tname}       is an array with names of tidal constituents to analyse
+
+ \np{nit000_han}{nit000\_han} and \np{nitend_han}{nitend\_han} must be between \np{nit000}{nit000} and \np{nitend}{nitend} of the simulation.
  The restart capability is not implemented.
 
@@ -1649 +1625 @@
 We obtain in output $C_{j}$ and $S_{j}$ for each tidal wave.
 
-% -------------------------------------------------------------------------------------------------------------
-%       Sections transports
-% -------------------------------------------------------------------------------------------------------------
-\section{Transports across sections (\protect\key{diadct}) }
+%% =================================================================================================
+\section[Transports across sections (\texttt{\textbf{key\_diadct}})]{Transports across sections (\protect\key{diadct})}
 \label{sec:DIA_diag_dct}
 
-%------------------------------------------namdct----------------------------------------------------
-
-\nlst{namdct}
-%-------------------------------------------------------------------------------------------------------------
+\begin{listing}
+  \nlst{nam_diadct}
+  \caption{\forcode{&nam_diadct}}
+  \label{lst:nam_diadct}
+\end{listing}
 
 A module is available to compute the transport of volume, heat and salt through sections.
@@ -1664 +1639 @@
 
 Each section is defined by the coordinates of its 2 extremities.
-The pathways between them are contructed using tools which can be found in \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT}
-and are written in a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by
-NEMO to compute on-line transports.
+The pathways between them are contructed using tools which can be found in \texttt{tools/SECTIONS\_DIADCT}
+and are written in a binary file \texttt{section\_ijglobal.diadct} which is later read in by
+\NEMO\ to compute on-line transports.
 
 The on-line transports module creates three output ascii files:
@@ -1676 +1651 @@
 - \texttt{salt\_transport}   for   salt transports (unit: $10^{9}Kg s^{-1}$) \\
 
-Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over which
+Namelist variables in \nam{_diadct}{\_diadct} control how frequently the flows are summed and the time scales over which
 they are averaged, as well as the level of output for debugging:
-\np{nn\_dct}   : frequency of instantaneous transports computing
-\np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports )
-\np{nn\_debug} : debugging of the section
-
+\np{nn_dct}{nn\_dct}   : frequency of instantaneous transports computing
+\np{nn_dctwri}{nn\_dctwri}: frequency of writing ( mean of instantaneous transports )
+\np{nn_debug}{nn\_debug} : debugging of the section
+
+%% =================================================================================================
 \subsubsection{Creating a binary file containing the pathway of each section}
 
-In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run},
+In \texttt{tools/SECTIONS\_DIADCT/run},
 the file \textit{ {list\_sections.ascii\_global}} contains a list of all the sections that are to be computed
 (this list of sections is based on MERSEA project metrics).
@@ -1691 +1667 @@
 
 Each section is defined by: \\
-\noindent {\scriptsize \texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}} \\
+\noindent { \texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}} \\
 with:
 
@@ -1698 +1674 @@
  - \texttt{long2 lat2}, coordinates of the second extremity of the section;
 
- - \texttt{nclass}    the number of bounds of your classes (\eg bounds for 2 classes);
+ - \texttt{nclass}    the number of bounds of your classes (\eg\ bounds for 2 classes);
 
  - \texttt{okstrpond} to compute    heat and       salt transports, \texttt{nostrpond} if no;
@@ -1708 +1684 @@
 
 \noindent If nclass $\neq$ 0, the next lines contain the class type and the nclass bounds: \\
-{\scriptsize
+{
   \texttt{
     long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name \\
@@ -1731 +1707 @@
 
  - \texttt{zsigp} for potential density classes \\
-  
+
  The script \texttt{job.ksh} computes the pathway for each section and creates a binary file
- \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\
+ \texttt{section\_ijglobal.diadct} which is read by \NEMO. \\
 
  It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated with
@@ -1741 +1717 @@
  and the ATL\_Cuba\_Florida with 4 temperature clases (5 class bounds), are shown: \\
  \noindent
- {\scriptsize
+ {
    \texttt{
      -68.    -54.5   -60.    -64.7  00 okstrpond noice ACC\_Drake\_Passage \\
@@ -1753 +1729 @@
  }
 
+%% =================================================================================================
 \subsubsection{To read the output files}
 
 The output format is: \\
-{\scriptsize
+{
   \texttt{
     date, time-step number, section number,                \\
@@ -1778 +1755 @@
 
 \begin{table}
-  \scriptsize
   \begin{tabular}{|l|l|l|l|l|}
     \hline
@@ -1792 +1768 @@
 \end{table}
 
-% ================================================================
-% Steric effect in sea surface height
-% ================================================================
+%% =================================================================================================
 \section{Diagnosing the steric effect in sea surface height}
 \label{sec:DIA_steric}
-
 
 Changes in steric sea level are caused when changes in the density of the water column imply an expansion or
@@ -1809 +1782 @@
 The steric effect is therefore not explicitely represented.
 This approximation does not represent a serious error with respect to the flow field calculated by the model
-\citep{Greatbatch_JGR94}, but extra attention is required when investigating sea level,
+\citep{greatbatch_JGR94}, but extra attention is required when investigating sea level,
 as steric changes are an important contribution to local changes in sea level on seasonal and climatic time scales.
 This is especially true for investigation into sea level rise due to global warming.
 
 Fortunately, the steric contribution to the sea level consists of a spatially uniform component that
-can be diagnosed by considering the mass budget of the world ocean \citep{Greatbatch_JGR94}.
+can be diagnosed by considering the mass budget of the world ocean \citep{greatbatch_JGR94}.
 In order to better understand how global mean sea level evolves and thus how the steric sea level can be diagnosed,
 we compare, in the following, the non-Boussinesq and Boussinesq cases.
 
 Let denote
-$\mathcal{M}$ the total mass    of liquid seawater ($\mathcal{M} = \int_D \rho dv$), 
-$\mathcal{V}$ the total volume  of        seawater      ($\mathcal{V} = \int_D dv$), 
-$\mathcal{A}$ the total surface of       the ocean      ($\mathcal{A} = \int_S ds$), 
-$\bar{\rho}$ the global mean  seawater (\textit{in situ}) density 
+$\mathcal{M}$ the total mass    of liquid seawater ($\mathcal{M} = \int_D \rho dv$),
+$\mathcal{V}$ the total volume  of        seawater      ($\mathcal{V} = \int_D dv$),
+$\mathcal{A}$ the total surface of       the ocean      ($\mathcal{A} = \int_S ds$),
+$\bar{\rho}$ the global mean  seawater (\textit{in situ}) density
 ($\bar{\rho} = 1/\mathcal{V} \int_D \rho \,dv$), and
-$\bar{\eta}$ the global mean sea level 
+$\bar{\eta}$ the global mean sea level
 ($\bar{\eta} = 1/\mathcal{A} \int_S \eta \,ds$).
 
@@ -1834 +1807 @@
     \mathcal{V} &=  \mathcal{A}  \;\bar{\eta}
   \end{split}
-  \label{eq:MV_nBq}
+  \label{eq:DIA_MV_nBq}
 \end{equation}
 
@@ -1842 +1815 @@
   \frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} )
   = \left. \frac{\textit{emp}}{e_3}\right|_\textit{surface}
-  \label{eq:Co_nBq}
+  \label{eq:DIA_Co_nBq}
 \end{equation}
 
 where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass exchanges with the other media of
 the Earth system (atmosphere, sea-ice, land).
-Its global averaged leads to the total mass change 
+Its global averaged leads to the total mass change
 
 \begin{equation}
   \partial_t \mathcal{M} = \mathcal{A} \;\overline{\textit{emp}}
-  \label{eq:Mass_nBq}
+  \label{eq:DIA_Mass_nBq}
 \end{equation}
 
 where $\overline{\textit{emp}} = \int_S \textit{emp}\,ds$ is the net mass flux through the ocean surface.
-Bringing \autoref{eq:Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to
+Bringing \autoref{eq:DIA_Mass_nBq} and the time derivative of \autoref{eq:DIA_MV_nBq} together leads to
 the evolution equation of the mean sea level
 
@@ -1861 +1834 @@
   \partial_t \bar{\eta} = \frac{\overline{\textit{emp}}}{ \bar{\rho}}
   - \frac{\mathcal{V}}{\mathcal{A}} \;\frac{\partial_t \bar{\rho} }{\bar{\rho}}
-  \label{eq:ssh_nBq}
+  \label{eq:DIA_ssh_nBq}
 \end{equation}
 
-The first term in equation \autoref{eq:ssh_nBq} alters sea level by adding or subtracting mass from the ocean. 
-The second term arises from temporal changes in the global mean density; \ie from steric effects.
+The first term in equation \autoref{eq:DIA_ssh_nBq} alters sea level by adding or subtracting mass from the ocean.
+The second term arises from temporal changes in the global mean density; \ie\ from steric effects.
 
 In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ appears multiplied by
-the gravity (\ie in the hydrostatic balance of the primitive Equations).
-In particular, the mass conservation equation, \autoref{eq:Co_nBq}, degenerates into the incompressibility equation:
+the gravity (\ie\ in the hydrostatic balance of the primitive Equations).
+In particular, the mass conservation equation, \autoref{eq:DIA_Co_nBq}, degenerates into the incompressibility equation:
 
 \[
   \frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) = \left. \frac{\textit{emp}}{\rho_o \,e_3}\right|_ \textit{surface}
-  % \label{eq:Co_Bq}
+  % \label{eq:DIA_Co_Bq}
 \]
 
@@ -1880 +1853 @@
 \[
   \partial_t \mathcal{V} = \mathcal{A} \;\frac{\overline{\textit{emp}}}{\rho_o}
-  % \label{eq:V_Bq}
+  % \label{eq:DIA_V_Bq}
 \]
 
@@ -1888 +1861 @@
 the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid.
 
-Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by
-considering the mass budget of the ocean. 
+Nevertheless, following \citep{greatbatch_JGR94}, the steric effect on the volume can be diagnosed by
+considering the mass budget of the ocean.
 The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface mass flux
 must be compensated by a spatially uniform change in the mean sea level due to expansion/contraction of the ocean
-\citep{Greatbatch_JGR94}.
+\citep{greatbatch_JGR94}.
 In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$,
 the total mass of the ocean seen by the Boussinesq model, via the steric contribution to the sea level,
@@ -1899 +1872 @@
 \begin{equation}
   \mathcal{M}_o = \mathcal{M} + \rho_o \,\eta_s \,\mathcal{A}
-  \label{eq:M_Bq}
+  \label{eq:DIA_M_Bq}
 \end{equation}
 
@@ -1905 +1878 @@
 is converted into a mean change in sea level.
 Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$,
-where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos})
-in \autoref{eq:M_Bq} leads to a very simple form for the steric height:
+where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO\ (cf. \autoref{subsec:TRA_eos})
+in \autoref{eq:DIA_M_Bq} leads to a very simple form for the steric height:
 
 \begin{equation}
   \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D}
-  \label{eq:steric_Bq}
+  \label{eq:DIA_steric_Bq}
 \end{equation}
 
 The above formulation of the steric height of a Boussinesq ocean requires four remarks.
 First, one can be tempted to define $\rho_o$ as the initial value of $\mathcal{M}/\mathcal{V}$,
-\ie set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero.
+\ie\ set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero.
 We do not recommend that.
 Indeed, in this case $\rho_o$ depends on the initial state of the ocean.
@@ -1924 +1897 @@
 This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since,
 with the exception of only a small percentage of the ocean, density in the World Ocean varies by no more than
-2$\%$ from this value (\cite{Gill1982}, page 47).
+2$\%$ from this value (\cite{gill_bk82}, page 47).
 
 Second, we have assumed here that the total ocean surface, $\mathcal{A}$,
 does not change when the sea level is changing as it is the case in all global ocean GCMs
 (wetting and drying of grid point is not allowed).
-  
-Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of free surface which is considered.
-In the non linear free surface case, \ie \key{vvl} defined, it is given by
+
+Third, the discretisation of \autoref{eq:DIA_steric_Bq} depends on the type of free surface which is considered.
+In the non linear free surface case, \ie\ \np[=.true.]{ln_linssh}{ln\_linssh}, it is given by
 
 \[
   \eta_s = - \frac{ \sum_{i,\,j,\,k} d_a\; e_{1t} e_{2t} e_{3t} }{ \sum_{i,\,j,\,k}       e_{1t} e_{2t} e_{3t} }
-  % \label{eq:discrete_steric_Bq_nfs}
+  % \label{eq:DIA_discrete_steric_Bq_nfs}
 \]
 
@@ -1945 +1918 @@
   \eta_s = - \frac{ \sum_{i,\,j,\,k} d_a\; e_{1t}e_{2t}e_{3t} + \sum_{i,\,j} d_a\; e_{1t}e_{2t} \eta }
                   { \sum_{i,\,j,\,k}       e_{1t}e_{2t}e_{3t} + \sum_{i,\,j}       e_{1t}e_{2t} \eta }
-  % \label{eq:discrete_steric_Bq_fs}
+  % \label{eq:DIA_discrete_steric_Bq_fs}
 \]
 
@@ -1954 +1927 @@
 so that there are no associated ocean currents.
 Hence, the dynamically relevant sea level is the effective sea level,
-\ie the sea level as if sea ice (and snow) were converted to liquid seawater \citep{Campin_al_OM08}.
-However, in the current version of \NEMO the sea-ice is levitating above the ocean without mass exchanges between
+\ie\ the sea level as if sea ice (and snow) were converted to liquid seawater \citep{campin.marshall.ea_OM08}.
+However, in the current version of \NEMO\ the sea-ice is levitating above the ocean without mass exchanges between
 ice and ocean.
 Therefore the model effective sea level is always given by $\eta + \eta_s$, whether or not there is sea ice present.
@@ -1965 +1938 @@
 \[
   \eta_s = - \frac{1}{\mathcal{A}} \int_D d_a(T,S_o,p_o) \,dv
-  % \label{eq:thermosteric_Bq}
+  % \label{eq:DIA_thermosteric_Bq}
 \]
 
 where $S_o$ and $p_o$ are the initial salinity and pressure, respectively.
 
-Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs the \key{diaar5} defined to
-be called.
-
-% -------------------------------------------------------------------------------------------------------------
-%       Other Diagnostics
-% -------------------------------------------------------------------------------------------------------------
-\section{Other diagnostics (\protect\key{diahth}, \protect\key{diaar5})}
+Both steric and thermosteric sea level are computed in \mdl{diaar5}.
+
+%% =================================================================================================
+\section{Other diagnostics}
 \label{sec:DIA_diag_others}
 
@@ -1982 +1952 @@
 The available ready-to-add diagnostics modules can be found in directory DIA.
 
-\subsection{Depth of various quantities (\protect\mdl{diahth})}
+%% =================================================================================================
+\subsection[Depth of various quantities (\textit{diahth.F90})]{Depth of various quantities (\protect\mdl{diahth})}
 
 Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key:
 
-- the mixed layer depth (based on a density criterion \citep{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth})
+- the mixed layer depth (based on a density criterion \citep{de-boyer-montegut.madec.ea_JGR04}) (\mdl{diahth})
 
 - the turbocline depth (based on a turbulent mixing coefficient criterion) (\mdl{diahth})
@@ -1994 +1965 @@
 - the depth of the thermocline (maximum of the vertical temperature gradient) (\mdl{diahth})
 
-% -----------------------------------------------------------
-%     Poleward heat and salt transports
-% -----------------------------------------------------------
-
-\subsection{Poleward heat and salt transports (\protect\mdl{diaptr})}
-
-%------------------------------------------namptr-----------------------------------------
-
-\nlst{namptr} 
-%-----------------------------------------------------------------------------------------
-
-The poleward heat and salt transports, their advective and diffusive component,
-and the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true
-(see the \textit{\ngn{namptr} } namelist below).
-When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic, Indian,
+\begin{figure}[!t]
+  \centering
+  \includegraphics[width=0.66\textwidth]{DIA_mask_subasins}
+  \caption[Decomposition of the World Ocean to compute transports as well as
+  the meridional stream-function]{
+    Decomposition of the World Ocean (here ORCA2) into sub-basin used in to
+    compute the heat and salt transports as well as the meridional stream-function:
+    Atlantic basin (red), Pacific basin (green),
+    Indian basin (blue), Indo-Pacific basin (blue+green).
+    Note that semi-enclosed seas (Red, Med and Baltic seas) as well as
+    Hudson Bay are removed from the sub-basins.
+    Note also that the Arctic Ocean has been split into Atlantic and
+    Pacific basins along the North fold line.
+  }
+  \label{fig:DIA_mask_subasins}
+\end{figure}
+
+%% =================================================================================================
+\subsection[CMIP specific diagnostics (\textit{diaar5.F90}, \textit{diaptr.F90})]{CMIP specific diagnostics (\protect\mdl{diaar5})}
+
+A series of diagnostics has been added in the \mdl{diaar5} and \mdl{diaptr}.
+In \mdl{diaar5} they correspond to outputs that are required for AR5 simulations (CMIP5)
+(see also \autoref{sec:DIA_steric} for one of them).
+The module \mdl{diaar5} is active when one of the following outputs is required :
+global total volume (voltot), global mean ssh (sshtot), global total mass (masstot), global mean temperature (temptot),
+global mean ssh steric (sshsteric), global mean ssh thermosteric (sshthster), global mean salinity (saltot),
+sea water pressure at sea floor (botpres), dynamic sea surface height (sshdyn).
+
+In \mdl{diaptr} when \np[=.true.]{ln_diaptr}{ln\_diaptr}
+(see the \nam{ptr}{ptr} namelist below) can be computed on-line the poleward heat and salt transports,
+their advective and diffusive component, and the meriodional stream function .
+When \np[=.true.]{ln_subbas}{ln\_subbas}, transports and stream function are computed for the Atlantic, Indian,
 Pacific and Indo-Pacific Oceans (defined north of 30\deg{S}) as well as for the World Ocean.
 The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains three 2D mask arrays,
-the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:mask_subasins}).
-
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-\begin{figure}[!t]
-  \begin{center}
-    \includegraphics[width=1.0\textwidth]{Fig_mask_subasins}
-    \caption{
-      \protect\label{fig:mask_subasins}
-      Decomposition of the World Ocean (here ORCA2) into sub-basin used in to
-      compute the heat and salt transports as well as the meridional stream-function:
-      Atlantic basin (red), Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green).
-      Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay are removed from the sub-basins.
-      Note also that the Arctic Ocean has been split into Atlantic and Pacific basins along the North fold line.
-    }
-  \end{center}
-\end{figure}  
-%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-
-% -----------------------------------------------------------
-%       CMIP specific diagnostics 
-% -----------------------------------------------------------
-\subsection{CMIP specific diagnostics (\protect\mdl{diaar5})}
-
-A series of diagnostics has been added in the \mdl{diaar5}.
-They corresponds to outputs that are required for AR5 simulations (CMIP5)
-(see also \autoref{sec:DIA_steric} for one of them).
-Activating those outputs requires to define the \key{diaar5} CPP key.
-
-% -----------------------------------------------------------
-%       25 hour mean and hourly Surface, Mid and Bed 
-% -----------------------------------------------------------
+the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:DIA_mask_subasins}).
+
+\begin{listing}
+  \nlst{namptr}
+  \caption{\forcode{&namptr}}
+  \label{lst:namptr}
+\end{listing}
+
+%% =================================================================================================
 \subsection{25 hour mean output for tidal models}
 
-%------------------------------------------nam_dia25h-------------------------------------
-
-\nlst{nam_dia25h}
-%-----------------------------------------------------------------------------------------
+\begin{listing}
+  \nlst{nam_dia25h}
+  \caption{\forcode{&nam_dia25h}}
+  \label{lst:nam_dia25h}
+\end{listing}
 
 A module is available to compute a crudely detided M2 signal by obtaining a 25 hour mean.
@@ -2054 +2021 @@
 This diagnostic is actived with the logical $ln\_dia25h$.
 
-% -----------------------------------------------------------
-%     Top Middle and Bed hourly output
-% -----------------------------------------------------------
+%% =================================================================================================
 \subsection{Top middle and bed hourly output}
 
-%------------------------------------------nam_diatmb-----------------------------------------------------
-
-\nlst{nam_diatmb}
-%----------------------------------------------------------------------------------------------------------
+\begin{listing}
+  \nlst{nam_diatmb}
+  \caption{\forcode{&nam_diatmb}}
+  \label{lst:nam_diatmb}
+\end{listing}
 
 A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables.
@@ -2070 +2036 @@
 This diagnostic is actived with the logical $ln\_diatmb$.
 
-% -----------------------------------------------------------
-%     Courant numbers
-% -----------------------------------------------------------
+%% =================================================================================================
 \subsection{Courant numbers}
 
@@ -2080 +2044 @@
 \[
   C_u = |u|\frac{\rdt}{e_{1u}}, \quad C_v = |v|\frac{\rdt}{e_{2v}}, \quad C_w = |w|\frac{\rdt}{e_{3w}}
-  % \label{eq:CFL}
+  % \label{eq:DIA_CFL}
 \]
 
@@ -2089 +2053 @@
 Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step.
 
-The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in the \ngn{namctl} namelist.
+The variables can be activated by setting the \np{nn_diacfl}{nn\_diacfl} namelist parameter to 1 in the \nam{ctl}{ctl} namelist.
 The diagnostics will be written out to an ascii file named cfl\_diagnostics.ascii.
 In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with the coordinates of
@@ -2095 +2059 @@
 At the end of the model run the maximum value of $C_u$, $C_v$, and $C_w$ for the whole model run is printed along
 with the coordinates of each.
-The maximum values from the run are also copied to the ocean.output file. 
-
-% ================================================================
-
-\biblio
-
-\pindex
+The maximum values from the run are also copied to the ocean.output file.
+
+\subinc{\input{../../global/epilogue}}
 
 \end{document}

@@ -1 @@
-*.aux
-*.bbl
-*.blg
-*.dvi
-*.fdb*
-*.fls
-*.idx
+*.ind
 *.ilg
-*.ind
-*.log
-*.maf
-*.mtc*
-*.out
-*.pdf
-*.toc
-_minted-*