Index: /NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex
===================================================================
--- /NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex	(revision 11217)
+++ /NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex	(revision 11218)
@@ -25,6 +25,5 @@
 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.
@@ -38,13 +37,4 @@
 the writing work is distributed over the processors in massively parallel computing.
 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
@@ -91,6 +81,9 @@
 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}).
@@ -101,5 +94,5 @@
 
 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} 
+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
@@ -257,6 +250,6 @@
 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.
+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}
@@ -269,5 +262,5 @@
 \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.
+  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
@@ -442,10 +435,12 @@
 \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" />
+<context id="nemo" src="./context_nemo.xml"/> 
 \end{xmllines}
 
@@ -508,5 +503,8 @@
 
 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,5 +512,5 @@
 <field_group id="groupU" >
 	<field field_ref="uoce"  />
-	<field field_ref="suoce" />
+	<field field_ref="ssu" />
 	<field field_ref="utau"  />
 </field_group>
@@ -538,10 +536,10 @@
 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 
+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,5 +549,5 @@
 \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}
@@ -576,12 +574,14 @@
 \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}
 
@@ -765,5 +765,5 @@
 \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.
@@ -1318,5 +1318,5 @@
 \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. 
@@ -1341,5 +1341,5 @@
 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
@@ -1464,5 +1464,5 @@
 (\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.
+Note that the output are done with XIOS, and therefore the \key{iomput} is required.
 
 What is done depends on the \ngn{namtrd} logical set to \forcode{.true.}:
@@ -1490,5 +1490,5 @@
 
 Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via 
-the \key{trdtrc} and \key{trdmld\_trc} CPP keys.
+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.
@@ -1509,5 +1509,5 @@
 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.
+Options are defined by \ngn{namflo} 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{ln\_flork4}\forcode{ = .true.}).
@@ -1522,5 +1522,5 @@
 In case of Ariane convention, input filename is \np{init\_float\_ariane}.
 Its format is: \\
-{\scriptsize \texttt{I J K nisobfl itrash itrash}}
+{\scriptsize \texttt{I J K nisobfl itrash}}
 
 \noindent with:
@@ -1580,8 +1580,6 @@
 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{ln\_flo\_ascii}\forcode{ = .false.}) with
+\key{iomput} and outputs selected in iodef.xml.
 Here it is an example of specification to put in files description section:
 
@@ -1600,8 +1598,4 @@
 \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.
 
 % -------------------------------------------------------------------------------------------------------------
@@ -1612,5 +1606,5 @@
 \label{sec:DIA_diag_harm}
 
-%------------------------------------------namdia_harm----------------------------------------------------
+%------------------------------------------nam_diaharm----------------------------------------------------
 %
 \nlst{nam_diaharm}
@@ -1620,5 +1614,5 @@
 This on-line Harmonic analysis is actived with \key{diaharm}.
 
-Some parameters are available in namelist \ngn{namdia\_harm}:
+Some parameters are available in namelist \ngn{nam\_diaharm}:
 
  - \np{nit000\_han} is the first time step used for harmonic analysis
@@ -1669,6 +1663,6 @@
 
 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
+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.
 
@@ -1689,5 +1683,5 @@
 \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).
@@ -1738,5 +1732,5 @@
   
  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
