Context Navigation

← Previous Change
Next Change →

chap_DIA.tex

Timestamp:

2019-08-14T14:45:08+02:00 (5 years ago)

Author:

nicolasmartin

Message:

Various corrections on chapters

Cleaning the indexes by fixing/removing wrong entries (or appending a ? to unknown items) and
improve the classification with new index definitions for CPP keys and namelist blocks:

from \key{...} cmd, key_ prefix no longer precedes the index entry
namelist block declaration moves from \ngn{nam...} to \nam{...} (i.e. \ngn{namtra\_ldf} -> \nam{tra\_ldf}) The expected prefix nam is added to the printed word but not the index entry.

Now we have indexes with a better sorting instead of all CPP keys under 'K' and namelists blocks under 'N'.

Fix missing space issues with alias commands by adding a trailing backslash (\NEMO\, \ie\, \eg\, ...).
There is no perfect solution for this, and I prefer not using a particular package to solve it.

Review the initial LaTeX code snippet for the historic changes in chapters

Finally, for readability and future diff visualisations, please avoid writing paragraphs with continuous lines.
Break the lines around 80 to 100 characters long

File:

: 1 edited

NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex (modified) (69 diffs)

Legend:

: Unmodified
: Added
: Removed

NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex

-                      r11346
+                      r11435
 \label{chap:DIA}
 \minitoc
+\chaptertoc
 \vfill
 …
     {\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 }  \\
+    {\em 3.4} & {\em Gurvan Madec, Rachid Benshila, Andrew Coward } & {\em }  \\
+    {\em }      & {\em Christian Ethe, Sebastien Masson } & {\em }  \\
 \end{tabular}
 \end{figure}
+\end{figure}
 \newpage
 % ================================================================
 %       Old Model Output
+%       Old Model Output
 % ================================================================
 \section{Model output}
 …
 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.
 …
 \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}
 …
 \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:
 …
 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:
+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},
 …
 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-2.5}{XIOS-2.5}
 (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
+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,
+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):
 …
 \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} 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}\forcode{ = 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}\forcode{ = 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.
 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} -
+   \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} -
 D 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[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
 written either by \rou{rst\_write} or by calling \rou{iom\_rstput} from individual routines.
 \end{description}
 …
 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
 …
 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.
 …
 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.
 …
 \subsubsection{Control of XIOS: the context in iodef.xml}
+As well as the {\ttfamily 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.
 …
     \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 &
 …
     \hline
     buffer\_server\_factor\_size                                            &
     ratio between NEMO and XIOS buffer size.
+    ratio between \NEMO\ and XIOS buffer size.
     Should be 2.                                                            &
         \\
 …
     \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   \\
 …
 \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.
+\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.
 …
 \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
 …
    <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>
+</field_definition>
 \end{xmllines}
 …
 \begin{xmllines}
 <file id="file1" .../>
+<file id="file1" .../>
 ...
    <field field_ref="identifier" />
+   <field field_ref="identifier" />
    ...
 </file>
+</file>
 \end{xmllines}
 …
 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:
 …
                                                                                                      \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
 …
 \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):
 …
 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 definition is done in 3 separate files (
+\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
 …
 are included in the main iodef.xml file through the following commands:
 \begin{xmllines}
 <context id="nemo" src="./context_nemo.xml"/>
+<context id="nemo" src="./context_nemo.xml"/>
 \end{xmllines}
 …
 \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}
 …
 </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}
 …
    <field_group group_ref="groupU" />
    <field field_ref="uocetr_eff"   />  <!-- add another field -->
 </file>
+</file>
 \end{xmllines}
 …
 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{cfgs/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).
 …
 \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.
 …
 \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.
 …
 \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"  -->
       ...
 …
 \end{table}
 \noindent For example,
+\noindent For example,
 \xmlline|<file id="myfile_hzoom" name="myfile_@expname@_@startdate@_freq@freq@" output_freq="1d" >|
 …
 \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.
 …
 \end{xmllines}
 Note that, then the code is crashing, writting real4 variables forces a numerical conversion 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.
 …
 \begin{xmllines}
 <file_group id="1d" output_freq="1d" output_level="10" enabled=".true."> <!-- 1d files -->
+<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" >
 …
       <variable id="my_global_attribute" type="string" > blabla_global </variable>
    </file>
 </file_group>
+</file_group>
 \end{xmllines}
 …
 \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}
 …
 \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}
 …
 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.
 …
 \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" >
 …
       </field>
    </file>
 </file_group>
+</file_group>
 \end{xmllines}
 …
 \subsection{CF metadata standard compliance}
 Output from the XIOS 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.
 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} in the \nam{run} namelist.
 This must be set to true if these metadata are to be included in the output files.
 …
 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:
+\NEMO\ executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by
+setting the \np{ln\_nc4zip} logical to false in the \nam{nc4} namelist:
 %------------------------------------------namnc4----------------------------------------------------
 …
 \noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\ttfamily 46x38x1} respectively in
 the mono-processor case (\ie global domain of {\small\ttfamily 182x149x31}).
 An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in
+the mono-processor case (\ie\ global domain of {\small\ttfamily 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
 a 4x2 mpi partitioning.
 …
 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} in
+\textit{xmlio\_server.def}.
+Typically this namelist serves the mean files whilst the \nam{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 (\texttt{namtrd})]
 {Tracer/Dynamics trends (\protect\ngn{namtrd})}
+{Tracer/Dynamics trends (\protect\nam{trd})}
 \label{sec:DIA_trd}
 %------------------------------------------namtrd----------------------------------------------------
 \nlst{namtrd}
+\nlst{namtrd}
 %-------------------------------------------------------------------------------------------------------------
 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.
+(\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} namelist.
 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.}:
+What is done depends on the \nam{trd} logical set to \forcode{.true.}:
 \begin{description}
 …
 \end{description}
 Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via
+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 \np{ln\_linssh}\forcode{ = .true.}).
+and none of the options have been tested with variable volume (\ie\ \np{ln\_linssh}\forcode{ = .true.}).
 % -------------------------------------------------------------------------------------------------------------
 …
 %--------------------------------------------namflo-------------------------------------------------------
 \nlst{namflo}
+\nlst{namflo}
 %--------------------------------------------------------------------------------------------------------------
 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} namelist variables.
+Options are defined by \nam{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{ln\_flork4}\forcode{ = .true.}).
 …
 (IJK coordinates, (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude.
 In case of Ariane convention, input filename is \np{init\_float\_ariane}.
+In case of Ariane convention, input filename is \textit{init\_float\_ariane}.
 Its format is: \\
 {\scriptsize \texttt{I J K nisobfl itrash}}
 …
  - 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
 …
 This on-line Harmonic analysis is actived with \key{diaharm}.
 Some parameters are available in namelist \ngn{nam\_diaharm}:
+Some parameters are available in namelist \nam{\_diaharm}:
  - \np{nit000\_han} is the first 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{nb\_ana}     is the number of harmonics to analyse
  - \np{tname}       is an array with names of tidal constituents to analyse
 …
 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.
+\NEMO\ to compute on-line transports.
 The on-line transports module creates three output ascii files:
 …
 - \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{dct} 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
 …
  - \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;
 …
  - \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} 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
 …
 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$).
 …
 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}
 …
 \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: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).
+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:
 …
 Nevertheless, following \citep{greatbatch_JGR94}, the steric effect on the volume can be diagnosed by
 considering the mass budget of the ocean.
+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
 …
 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})
+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:
 …
 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.
 …
 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 \np{ln\_linssh}\forcode{ = .true.}, it is given by
+In the non linear free surface case, \ie\ \np{ln\_linssh}\forcode{ = .true.}, it is given by
 \[
 …
 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.marshall.ea_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.
 …
+    }
   \end{center}
 \end{figure}
+\end{figure}
 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 % -----------------------------------------------------------
 %       CMIP specific diagnostics
+%       CMIP specific diagnostics
 % -----------------------------------------------------------
 \subsection[CMIP specific diagnostics (\textit{diaar5.F90}, \textit{diaptr.F90})]
 …
 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{ln\_diaptr}\forcode{ = .true.}
+(see the \textit{\ngn{namptr} } namelist below) can be computed on-line the poleward heat and salt transports, their advective and diffusive component, and the meriodional stream function .
+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{ln\_diaptr}\forcode{ = .true.}
+(see the \nam{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{ln\_subbas}\forcode{ = .true.}, 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.
 …
 %------------------------------------------namptr-----------------------------------------
 \nlst{namptr}
+\nlst{namptr}
 %-----------------------------------------------------------------------------------------
 % -----------------------------------------------------------
 %       25 hour mean and hourly Surface, Mid and Bed
+%       25 hour mean and hourly Surface, Mid and Bed
 % -----------------------------------------------------------
 \subsection{25 hour mean output for tidal models}
 …
 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} namelist parameter to 1 in the \nam{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
 …
 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.
+The maximum values from the run are also copied to the ocean.output file.
 % ================================================================

Note: See TracChangeset for help on using the changeset viewer.

New URL for NEMO forge! http://forge.nemo-ocean.eu

Context Navigation

Changeset 11435 for NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex

Legend:

NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex

Download in other formats: