source: branches/2017/dev_merge_2017/DOC/texfiles/chapters/chap_DIA.tex @ 9376

Last change on this file since 9376 was 9376, checked in by nicolasmartin, 2 years ago

Global reorganisation of DOC directory: refactoring & cleaning of TeX source code for readability

  • Property svn:keywords set to Id
File size: 79.8 KB
Line 
1\documentclass[NEMO_book]{subfiles}
2\begin{document}
3% ================================================================
4% Chapter I/O & Diagnostics
5% ================================================================
6\chapter{Output and Diagnostics (IOM, DIA, TRD, FLO)}
7\label{DIA}
8\minitoc
9
10\newpage
11$\ $\newline    % force a new line
12
13% ================================================================
14%       Old Model Output
15% ================================================================
16\section{Old Model Output (default)}
17\label{DIA_io_old}
18
19The model outputs are of three types: the restart file, the output listing,
20and the diagnostic output file(s). The restart file is used internally by the code when
21the user wants to start the model with initial conditions defined by a
22previous simulation. It contains all the information that is necessary in
23order for there to be no changes in the model results (even at the computer
24precision) between a run performed with several restarts and the same run
25performed in one step. It should be noted that this requires that the restart file
26contain two consecutive time steps for all the prognostic variables, and
27that it is saved in the same binary format as the one used by the computer
28that is to read it (in particular, 32 bits binary IEEE format must not be used for
29this file).
30
31The output listing and file(s) are predefined but should be checked
32and eventually adapted to the user's needs. The output listing is stored in
33the $ocean.output$ file. The information is printed from within the code on the
34logical unit $numout$. To locate these prints, use the UNIX command
35"\textit{grep -i numout}" in the source code directory.
36
37By default, diagnostic output files are written in NetCDF format.
38Since version 3.2, when defining \key{iomput}, an I/O server has been added
39which provides more flexibility in the choice of the fields to be written
40as well as how the writing work is distributed over the processors in massively parallel computing.
41A complete description of the use of this I/O server is presented in the next section.
42
43By default, \key{iomput} is not defined, NEMO produces NetCDF with the old IOIPSL library
44which has been kept for compatibility and its easy installation.
45However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2,
46many diagnostic options have been added presuming the use of \key{iomput}.
47The usefulness of the default IOIPSL-based option is expected to reduce with each new release.
48If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module
49and contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period
50of nn\_write time-steps (namelist parameter).
51
52%\gmcomment{                    % start of gmcomment
53
54% ================================================================
55% Diagnostics
56% ================================================================
57\section{Standard model Output (IOM)}
58\label{DIA_iom}
59
60
61Since version 3.2, iomput is the NEMO output interface of choice.
62It has been designed to be simple to use, flexible and efficient.
63The two main purposes of iomput are:
64\begin{enumerate}
65\item The complete and flexible control of the output files through external XML files
66adapted by the user from standard templates.
67\item To achieve high performance and scalable output through the optional distribution
68of all diagnostic output related tasks to dedicated processes.
69\end{enumerate}
70The first functionality allows the user to specify, without code changes or recompilation,
71aspects of the diagnostic output stream, such as:
72\begin{itemize}
73\item The choice of output frequencies that can be different for each file (including real months and years).
74\item The choice of file contents; includes complete flexibility over which data are written in which files
75(the same data can be written in different files).
76\item The possibility to split output files at a chosen frequency.
77\item The possibility to extract a vertical or an horizontal subdomain.
78\item The choice of the temporal operation to perform, e.g.: average, accumulate, instantaneous, min, max and once.
79\item Control over metadata via a large XML "database" of possible output fields.
80\end{itemize}
81In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or 3D)
82in a very easy way. All details of iomput functionalities are listed in the following subsections.
83Examples of the XML files that control the outputs can be found in:
84\path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml}, \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and
85\path{NEMOGCM/CONFIG/SHARED/domain_def.xml}.
86
87The second functionality targets output performance when running in parallel (\key{mpp\_mpi}).
88Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes)
89to collect and write the outputs. With an appropriate choice of N by the user,
90the bottleneck associated with the writing of the output files can be greatly reduced.
91
92In version 3.6, the iom\_put interface depends on an external code called
93\href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0} 
94(use of revision 618 or higher is required). This new IO server can take advantage of
95the parallel I/O functionality of NetCDF4 to create a single output file and therefore
96to bypass the rebuilding phase. Note that writing in parallel into the same NetCDF files
97requires that your NetCDF4 library is linked to an HDF5 library that has been correctly compiled
98($i.e.$ with the configure option $--$enable-parallel).
99Note that the files created by iomput through XIOS are incompatible with NetCDF3.
100All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3.
101
102Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers,
103where N is typically much less than the number of NEMO processors, will reduce the number of output files created.
104This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors.
105Note that for smaller configurations, the rebuilding phase can be avoided,
106even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server.
107
108\subsection{XIOS: the IO\_SERVER}
109
110\subsubsection{Attached or detached mode?}
111
112Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS},
113the io\_server developed by Yann Meurdesoif from IPSL.
114The behaviour of the I/O subsystem is controlled by settings in the external XML files listed above.
115Key settings in the iodef.xml file are {\tt using\_server} and the {\tt type} tag associated with each defined file.
116The {\tt using\_server} setting determines whether or not the server will be used in \textit{attached mode} (as a library)
117[{\tt false}] or in \textit{detached mode} (as an external executable on N additional, dedicated cpus) [{\tt true}].
118The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications.
119The type of each file can be either ''multiple\_file'' or ''one\_file''.
120
121In \textit{attached mode} and if the type of file is ''multiple\_file'',
122then each NEMO process will also act as an IO server and produce its own set of output files.
123Superficially, this emulates the standard behaviour in previous versions.
124However, the subdomain written out by each process does not correspond to the {\tt jpi x jpj x jpk} 
125domain actually computed by the process (although it may if {\tt jpni=1}).
126Instead each process will have collected and written out a number of complete longitudinal strips.
127If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips
128and write (in parallel) to a single output file.
129
130In \textit{detached mode} and if the type of file is ''multiple\_file'',
131then each stand-alone XIOS process will collect data for a range of complete longitudinal strips
132and write to its own set of output files. If the ''one\_file'' option is chosen then
133all XIOS processes will collect their longitudinal strips and write (in parallel) to a single output file.
134Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job.
135The following subsection provides a typical example but the syntax will vary in different MPP environments.
136
137\subsubsection{Number of cpu used by XIOS in detached mode}
138
139The number of cores used by the XIOS is specified when launching the model.
140The number of cores dedicated to XIOS should be from ~1/10 to ~1/50 of the number or cores dedicated to NEMO.
141Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors
142but this is a general recommendation and not specific to NEMO.
143It is difficult to provide precise recommendations because the optimal choice will depend on
144the particular hardware properties of the target system (parallel filesystem performance, available memory,
145memory bandwidth etc.) and the volume and frequency of data to be created.
146Here is an example of 2 cpus for the io\_server and 62 cpu for nemo using mpirun:
147
148\texttt{ mpirun -np 62 ./nemo.exe : -np 2 ./xios\_server.exe }
149
150\subsubsection{Control of XIOS: the XIOS context in iodef.xml}
151
152As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml.
153See the XML basics section below for more details on XML syntax and rules.
154
155\begin{tabular}{|p{4cm}|p{6.0cm}|p{2.0cm}|}
156   \hline
157   variable name & 
158   description & 
159   example \\ 
160   \hline   
161   \hline
162   buffer\_size & 
163   buffer size used by XIOS to send data from NEMO to XIOS. Larger is more efficient.
164   Note that needed/used buffer sizes are summarized at the end of the job & 
165   25000000 \\ 
166   \hline   
167   buffer\_server\_factor\_size & 
168   ratio between NEMO and XIOS buffer size. Should be 2. & 
169   2 \\ 
170   \hline
171   info\_level & 
172   verbosity level (0 to 100) & 
173   0 \\ 
174   \hline
175   using\_server & 
176   activate attached(false) or detached(true) mode & 
177   true \\ 
178   \hline
179   using\_oasis & 
180   XIOS is used with OASIS(true) or not (false) & 
181   false \\ 
182   \hline
183   oasis\_codes\_id & 
184   when using oasis, define the identifier of NEMO in the namcouple. Note that the identifier of XIOS is xios.x & 
185   oceanx \\ 
186   \hline   
187\end{tabular}
188
189
190\subsection{Practical issues}
191
192\subsubsection{Installation}
193
194As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO.
195See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance.
196NEMO will need to link to the compiled XIOS library.
197The \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS}{XIOS with NEMO} 
198guide provides an example illustration of how this can be achieved.
199
200\subsubsection{Add your own outputs}
201
202It is very easy to add your own outputs with iomput.
203Many standard fields and diagnostics are already prepared ($i.e.$, steps 1 to 3 below have been done)
204and simply need to be activated by including the required output in a file definition in iodef.xml (step 4).
205To add new output variables, all 4 of the following steps must be taken.
206\begin{description}
207\item[1.] in NEMO code, add a \\
208\texttt{      CALL iom\_put( 'identifier', array ) } \\
209where you want to output a 2D or 3D array.
210
211\item[2.] If necessary, add \\
212\texttt{   USE iom\ \ \ \ \ \ \ \ \ \ \ \ ! I/O manager library }  \\
213to the list of used modules in the upper part of your module.
214
215\item[3.] in the field\_def.xml file, add the definition of your variable using the same identifier
216you used in the f90 code (see subsequent sections for a details of the XML syntax and rules).
217For example:
218\vspace{-20pt}
219\begin{xmlcode}
220   <field_definition>
221      <!-- T grid -->
222
223     <field_group id="grid_T" grid_ref="grid_T_3D">
224      ...
225      <field id="identifier" long_name="blabla" ... />   
226      ...
227   </field_definition>
228\end{xmlcode}
229Note your definition must be added to the field\_group whose reference grid is consistent
230with the size of the array passed to iomput.
231The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids
232and axes either defined in the code (iom\_set\_domain\_attr and iom\_set\_axis\_attr in iom.F90)
233or defined in the domain\_def.xml file. $e.g.$:
234\vspace{-20pt}
235\begin{xmlcode}
236     <grid id="grid_T_3D" domain_ref="grid_T" axis_ref="deptht"/>
237\end{xmlcode}
238Note, if your array is computed within the surface module each nn\_fsbc time\_step,
239add the field definition within the field\_group defined with the id ''SBC'': $<$field\_group id=''SBC''...$>$ 
240which has been defined with the correct frequency of operations (iom\_set\_field\_attr in iom.F90)
241
242\item[4.] add your field in one of the output files defined in iodef.xml (again see subsequent sections for syntax and rules)   \\
243\vspace{-20pt}
244\begin{xmlcode}
245   <file id="file1" .../>   
246      ...
247      <field field_ref="identifier" />   
248      ...
249   </file>   
250\end{xmlcode}
251
252\end{description}
253\subsection{XML fundamentals}
254
255\subsubsection{ XML basic rules}
256
257XML tags begin with the less-than character ("$<$") and end with the greater-than character (''$>$'').
258You use tags to mark the start and end of elements, which are the logical units of information
259in an XML document. In addition to marking the beginning of an element, XML start tags also
260provide a place to specify attributes. An attribute specifies a single property for an element,
261using a name/value pair, for example: $<$a b="x" c="y" b="z"$>$ ... $<$/a$>$.
262See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details.
263
264\subsubsection{Structure of the xml file used in NEMO}
265
266The XML file used in XIOS is structured by 7 families of tags: context, axis, domain, grid, field, file and variable.
267Each tag family has hierarchy of three flavors (except for context):
268\\
269\begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|}
270   \hline
271   flavor &
272   description &
273   example \\
274   \hline
275   \hline
276   root &
277   declaration of the root element that can contain element groups or elements &
278   {\scriptsize \verb? < file_definition ... >?} \\
279   \hline
280   group &
281   declaration of a group element that can contain element groups or elements &
282   {\scriptsize \verb? < file_group ... >?} \\
283   \hline
284   element &
285   declaration of an element that can contain elements &
286   {\scriptsize \verb? < file ... >?} \\
287   \hline
288\end{tabular}
289\\
290
291Each element may have several attributes.
292Some attributes are mandatory, other are optional but have a default value and other are are completely optional.
293Id is a special attribute used to identify an element or a group of elements.
294It must be unique for a kind of element.
295It is optional, but no reference to the corresponding element can be done if it is not defined.
296
297The XML file is split into context tags that are used to isolate IO definition from different codes
298or different parts of a code. No interference is possible between 2 different contexts.
299Each context has its own calendar and an associated timestep.
300In \NEMO, we used the following contexts (that can be defined in any order):\\
301\\
302\begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|}
303   \hline
304   context &
305   description &
306   example \\
307   \hline
308   \hline
309   context xios &
310   context containing information for XIOS &
311   {\scriptsize \verb? <context id="xios" ...  ?} \\
312   \hline
313   context nemo &
314   context containing IO information for NEMO (mother grid when using AGRIF) &
315   {\scriptsize \verb? <context id="nemo" ... ?} \\
316   \hline
317   context 1\_nemo &
318   context containing IO information for NEMO child grid 1 (when using AGRIF) &
319   {\scriptsize \verb? <context id="1_nemo" ...  ?} \\
320   \hline
321   context n\_nemo &
322   context containing IO information for NEMO child grid n (when using AGRIF) &
323   {\scriptsize \verb? <context id="n_nemo" ...  ?} \\
324   \hline
325\end{tabular}
326\\
327
328\noindent The xios context contains only 1 tag:
329\\
330\begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|}
331   \hline
332   context tag &
333   description &
334   example \\
335   \hline
336   \hline
337   variable\_definition &
338   define variables needed by XIOS. This can be seen as a kind of namelist for XIOS. &
339   {\scriptsize \verb? <variable_definition ... ?} \\
340   \hline
341\end{tabular}
342\\
343
344\noindent Each context tag related to NEMO (mother or child grids) is divided into 5 parts
345(that can be defined in any order):\\
346\\
347\begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|}
348   \hline
349   context tag &
350   description &
351   example \\
352   \hline
353   \hline
354   field\_definition &
355   define all variables that can potentially be outputted &
356   {\scriptsize \verb? <field_definition ... ?} \\
357   \hline
358   file\_definition &
359   define the netcdf files to be created and the variables they will contain &
360   {\scriptsize \verb? <file_definition ... ?} \\
361   \hline
362   axis\_definition &
363   define vertical axis &
364   {\scriptsize \verb? <axis_definition ... ?} \\
365   \hline
366   domain\_definition &
367   define the horizontal grids &
368   {\scriptsize \verb? <domain_definition ... ?} \\
369   \hline
370   grid\_definition &
371   define the 2D and 3D grids (association of an axis and a domain) &
372   {\scriptsize \verb? <grid_definition ... ?} \\
373   \hline
374\end{tabular}
375\\
376
377\subsubsection{Nesting XML files}
378
379The XML file can be split in different parts to improve its readability and facilitate its use.
380The inclusion of XML files into the main XML file can be done through the attribute src: \\
381{\scriptsize \verb? <context src="./nemo_def.xml" /> ?}\\
382 
383\noindent In NEMO, by default, the field and domain definition is done in 2 separate files:
384\path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}
385
386\noindent that are included in the main iodef.xml file through the following commands: \\
387{\scriptsize \verb? <field_definition src="./field_def.xml" /> ? \\
388\verb? <domain_definition src="./domain_def.xml" /> ? }
389
390
391\subsubsection{Use of inheritance}
392
393XML extensively uses the concept of inheritance.
394XML has a tree based structure with a parent-child oriented relation:
395all children inherit attributes from parent, but an attribute defined in a child replace the inherited attribute value.
396Note that the special attribute ''id'' is never inherited.  \\
397\\
398example 1: Direct inheritance.
399\vspace{-20pt}
400\begin{xmlcode}
401   <field_definition operation="average" >
402     <field id="sst"                    />   <!-- averaged      sst -->
403     <field id="sss" operation="instant"/>   <!-- instantaneous sss -->
404   </field_definition>
405\end{xmlcode}
406The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average''
407of the attribute ''operation'' from its parent. Note that a child can overwrite
408the attribute definition inherited from its parents. In the example above, the field ''sss'' will
409for example output instantaneous values instead of average values. \\
410\\
411example 2: Inheritance by reference.
412\vspace{-20pt}
413\begin{xmlcode}
414   <field_definition>
415     <field id="sst" long_name="sea surface temperature" />   
416     <field id="sss" long_name="sea surface salinity"    /> 
417   </field_definition>     
418
419   <file_definition>
420     <file id="myfile" output_freq="1d" />   
421       <field field_ref="sst"                            />  <!-- default def -->
422       <field field_ref="sss" long_name="my description" />  <!-- overwrite   -->
423     </file>   
424   </file_definition>
425\end{xmlcode}
426Inherit (and overwrite, if needed) the attributes of a tag you are refering to.
427
428\subsubsection{Use of Groups}
429
430Groups can be used for 2 purposes.
431Firstly, the group can be used to define common attributes to be shared by the elements of the group through inheritance.
432In the following example, we define a group of field that will share a common grid ''grid\_T\_2D''.
433Note that for the field ''toce'', we overwrite the grid definition inherited from the group by ''grid\_T\_3D''.
434\vspace{-20pt}
435\begin{xmlcode}
436   <field_group id="grid_T" grid_ref="grid_T_2D">
437    <field id="toce" long_name="temperature"             unit="degC" grid_ref="grid_T_3D"/>
438    <field id="sst"  long_name="sea surface temperature" unit="degC"                     />
439    <field id="sss"  long_name="sea surface salinity"    unit="psu"                      />
440    <field id="ssh"  long_name="sea surface height"      unit="m"                        />
441         ...
442\end{xmlcode}
443
444Secondly, the group can be used to replace a list of elements.
445Several examples of groups of fields are proposed at the end of the file {\tt CONFIG/SHARED/field\_def.xml}.
446For example, a short list of the usual variables related to the U grid:
447\vspace{-20pt}
448\begin{xmlcode}
449   <field_group id="groupU" >
450    <field field_ref="uoce"  />
451    <field field_ref="suoce" />
452    <field field_ref="utau"  />
453   </field_group>
454\end{xmlcode}
455that can be directly included in a file through the following syntax:
456\vspace{-20pt}
457\begin{xmlcode}
458   <file id="myfile_U" output_freq="1d" />   
459    <field_group group_ref="groupU"/> 
460    <field field_ref="uocetr_eff"  />  <!-- add another field -->
461   </file>   
462\end{xmlcode}
463
464\subsection{Detailed functionalities }
465
466The file {\tt NEMOGCM/CONFIG/ORCA2\_LIM/iodef\_demo.xml} provides several examples of the use
467of the new functionalities offered by the XML interface of XIOS.
468
469\subsubsection{Define horizontal subdomains}
470Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of the tag family domain.
471It must therefore be done in the domain part of the XML file.
472For example, in {\tt CONFIG/SHARED/domain\_def.xml}, we provide the following example of a definition
473of a 5 by 5 box with the bottom left corner at point (10,10).
474\vspace{-20pt}
475\begin{xmlcode}
476   <domain_group id="grid_T">
477    <domain id="myzoom" zoom_ibegin="10" zoom_jbegin="10" zoom_ni="5" zoom_nj="5" />
478\end{xmlcode}
479The use of this subdomain is done through the redefinition of the attribute domain\_ref of the tag family field. For example:
480\vspace{-20pt}
481\begin{xmlcode}
482   <file id="myfile_vzoom" output_freq="1d" >
483      <field field_ref="toce" domain_ref="myzoom"/>
484   </file>
485\end{xmlcode}
486Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain.
487The Equatorial section, the TAO, RAMA and PIRATA moorings are alredy registered in the code
488and can therefore be outputted without taking care of their (i,j) position in the grid.
489These predefined domains can be activated by the use of specific domain\_ref: ''EqT'', ''EqU'' or ''EqW''
490for the equatorial sections and the mooring position for TAO, RAMA and PIRATA followed
491by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...)
492\vspace{-20pt}
493\begin{xmlcode}
494   <file id="myfile_vzoom" output_freq="1d" >
495      <field field_ref="toce" domain_ref="0n180wT"/>
496   </file>
497\end{xmlcode}
498Note 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.
499
500\subsubsection{Define vertical zooms}
501Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis. It must therefore be done in the axis part of the XML file. For example, in NEMOGCM/CONFIG/ORCA2\_LIM/iodef\_demo.xml, we provide the following example:
502\vspace{-20pt}
503\begin{xmlcode}
504   <axis_group id="deptht" long_name="Vertical T levels" unit="m" positive="down" >
505      <axis id="deptht" />
506      <axis id="deptht_myzoom" zoom_begin="1" zoom_end="10" />
507\end{xmlcode}
508The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of the tag family field. For example:
509\vspace{-20pt}
510\begin{xmlcode}
511   <file id="myfile_hzoom" output_freq="1d" >
512      <field field_ref="toce" axis_ref="deptht_myzoom"/>
513   </file>
514\end{xmlcode}
515
516\subsubsection{Control of the output file names}
517
518The output file names are defined by the attributs ''name'' and ''name\_suffix'' of the tag family file. for example:
519\vspace{-20pt}
520\begin{xmlcode}
521   <file_group id="1d" output_freq="1d" name="myfile_1d" >
522      <file id="myfileA" name_suffix="_AAA" > <!-- will create file "myfile_1d_AAA"  -->
523         ...
524      </file>
525      <file id="myfileB" name_suffix="_BBB" > <!-- will create file "myfile_1d_BBB" -->
526         ...
527      </file>
528   </file_group>
529\end{xmlcode}
530However it is often very convienent to define the file name with the name of the experiment, the output file frequency and the date of the beginning and the end of the simulation (which are informations stored either in the namelist or in the XML file). To do so, we added the following rule: if the id of the tag file is ''fileN''(where N = 1 to 999 on 1 to 3 digits) or one of the predefined sections or moorings (see next subsection), the following part of the name and the name\_suffix (that can be inherited) will be automatically replaced by:\\
531\\
532\begin{tabular}{|p{4cm}|p{8cm}|}
533   \hline
534   \centering placeholder string & automatically  replaced by \\
535   \hline
536   \hline
537   \centering @expname@ &
538   the experiment name (from cn\_exp in the namelist) \\
539   \hline
540   \centering @freq@ &
541   output frequency (from attribute output\_freq) \\
542   \hline
543   \centering @startdate@  &
544   starting date of the simulation (from nn\_date0 in the restart or the namelist). \verb?yyyymmdd? format \\
545   \hline
546   \centering @startdatefull@  & 
547   starting date of the simulation (from nn\_date0 in the restart or the namelist). \verb?yyyymmdd_hh:mm:ss? format \\
548   \hline
549   \centering @enddate@  &
550   ending date of the simulation (from nn\_date0 and nn\_itend in the namelist). \verb?yyyymmdd? format \\
551   \hline
552   \centering @enddatefull@  & 
553   ending date of the simulation (from nn\_date0 and nn\_itend in the namelist). \verb?yyyymmdd_hh:mm:ss? format \\
554   \hline
555\end{tabular}\\
556\\
557
558\noindent For example,
559{{\scriptsize
560\begin{verbatim}
561   <file id="myfile_hzoom" name="myfile_@expname@_@startdate@_freq@freq@" output_freq="1d" >
562\end{verbatim}
563}}
564\noindent with the namelist:
565{{\scriptsize
566\begin{verbatim}
567   cn_exp      =  "ORCA2"
568   nn_date0    =  19891231
569   ln_rstart   = .false.
570\end{verbatim}
571}}
572\noindent will give the following file name radical:
573{{\scriptsize
574\begin{verbatim}
575   myfile_ORCA2_19891231_freq1d
576\end{verbatim}
577}}
578
579\subsubsection{Other controls of the xml attributes from NEMO}
580
581The 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 iom.F90). Any definition given in the xml file will be overwritten. By convention, these attributes are defined to ''auto'' (for string) or ''0000'' (for integer) in the xml file (but this is not necessary).
582
583Here is the list of these attributes:\\
584\\
585\begin{tabular}{|l|c|c|c|}
586   \hline
587 \multicolumn{2}{|c|}{tag ids affected by automatic           }  & name      & attribute value \\
588  \multicolumn{2}{|c|}{definition of some of their attributes }  & attribute  &        \\
589   \hline
590   \hline
591    \multicolumn{2}{|c|}{field\_definition} & freq\_op & \np{rn\_rdt} \\
592   \hline
593    \multicolumn{2}{|c|}{SBC}               & freq\_op & \np{rn\_rdt} $\times$ \np{nn\_fsbc}  \\
594   \hline
595    \multicolumn{2}{|c|}{ptrc\_T}           & freq\_op & \np{rn\_rdt} $\times$ \np{nn\_dttrc} \\
596   \hline
597    \multicolumn{2}{|c|}{diad\_T}           & freq\_op & \np{rn\_rdt} $\times$ \np{nn\_dttrc} \\
598   \hline
599    \multicolumn{2}{|c|}{EqT, EqU, EqW} & jbegin, ni,      & according to the grid    \\
600    \multicolumn{2}{|c|}{                         } & name\_suffix &                                      \\
601   \hline
602   \multicolumn{2}{|c|}{TAO, RAMA and PIRATA moorings} & zoom\_ibegin, zoom\_jbegin, & according to the grid    \\
603    \multicolumn{2}{|c|}{                                                       } & name\_suffix &                                      \\
604   \hline
605\end{tabular}
606
607\subsubsection{Advanced use of XIOS functionalities}
608
609\subsection{XML reference tables}
610\label{IOM_xmlref}
611
612(1) Simple computation: directly define the computation when refering to the variable in the file definition.
613
614\vspace{-20pt}
615\begin{xmlcode}
616 <field field\_ref="sst"  name="tosK"  unit="degK" > sst + 273.15 </field>
617 <field field\_ref="taum" name="taum2" unit="N2/m4" long\_name="square of wind stress module" > taum * taum </field>
618 <field field\_ref="qt"   name="stupid\_check" > qt - qsr - qns </field>
619\end{xmlcode}
620
621(2) Simple computation: define a new variable and use it in the file definition.
622
623in field\_definition:
624\vspace{-20pt}
625\begin{xmlcode}
626 <field id="sst2" long\_name="square of sea surface temperature" unit="degC2" >  sst * sst </field >
627\end{xmlcode}
628in file\_definition:
629\vspace{-20pt}
630\begin{xmlcode}
631 <field field\_ref="sst2" > sst2 </field>
632\end{xmlcode}
633Note that in this case, the following syntaxe $<$field field\_ref="sst2" /$>$ is not working as sst2 won't be evaluated.
634
635(3) Change of variable precision:
636
637\vspace{-20pt}
638\begin{xmlcode}
639     <!-- force to keep real 8 -->
640 <field field\_ref="sst" name="tos\_r8" prec="8" />
641      <!-- integer 2  with add\_offset and scale\_factor attributes -->
642 <field field\_ref="sss" name="sos\_i2" prec="2" add\_offset="20." scale\_factor="1.e-3" />
643\end{xmlcode}
644Note that, then the code is crashing, writting real4 variables forces a numerical convection 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.
645
646(4) add user defined attributes:
647
648\vspace{-20pt}
649\begin{xmlcode}
650      <file\_group id="1d" output\_freq="1d" output\_level="10" enabled=".TRUE."> <!-- 1d files -->
651   <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >
652     <field field\_ref="sst" name="tos" >
653       <variable id="my\_attribute1" type="string"  > blabla </variable>
654       <variable id="my\_attribute2" type="integer" > 3      </variable>
655       <variable id="my\_attribute3" type="float"   > 5.0    </variable>
656     </field>
657     <variable id="my\_global\_attribute" type="string" > blabla\_global </variable>
658       </file>
659     </file\_group>
660\end{xmlcode}
661
662(5) use of the ``@'' function: example 1, weighted temporal average
663
664 - define a new variable in field\_definition
665\vspace{-20pt}
666\begin{xmlcode}
667 <field id="toce\_e3t" long\_name="temperature * e3t" unit="degC*m" grid\_ref="grid\_T\_3D" > toce * e3t </field >
668\end{xmlcode}
669 - use it when defining your file. 
670\vspace{-20pt}
671\begin{xmlcode}
672<file\_group id="5d" output\_freq="5d"  output\_level="10" enabled=".TRUE." >  <!-- 5d files --> 
673 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >
674  <field field\_ref="toce" operation="instant" freq\_op="5d" > @toce\_e3t / @e3t </field>
675 </file>
676</file\_group>
677\end{xmlcode}
678The freq\_op="5d" attribute is used to define the operation frequency of the ``@'' function: here 5 day. The temporal operation done by the ``@'' is the one defined in the field definition: here we use the default, average. So, in the above case, @toce\_e3t will do the 5-day mean of toce*e3t. Operation="instant" refers to the temporal operation to be performed on the field''@toce\_e3t / @e3t'': here the temporal average is alreday done by the ``@'' function so we just use instant to do the ratio of the 2 mean values. field\_ref="toce" means that attributes not explicitely defined, are inherited from toce field. Note that in this case, freq\_op must be equal to the file output\_freq.
679
680(6) use of the ``@'' function: example 2, monthly SSH standard deviation
681
682 - define a new variable in field\_definition
683\vspace{-20pt}
684\begin{xmlcode}
685 <field id="ssh2" long\_name="square of sea surface temperature" unit="degC2" >  ssh * ssh </field >
686\end{xmlcode}
687 - use it when defining your file. 
688\vspace{-20pt}
689\begin{xmlcode}
690<file\_group id="1m" output\_freq="1m"  output\_level="10" enabled=".TRUE." >  <!-- 1m files --> 
691 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >
692  <field field\_ref="ssh" name="sshstd" long\_name="sea\_surface\_temperature\_standard\_deviation" operation="instant" freq\_op="1m" > sqrt( @ssh2 - @ssh * @ssh ) </field>
693 </file>
694</file\_group>
695\end{xmlcode}
696The freq\_op="1m" attribute is used to define the operation frequency of the ``@'' function: here 1 month. The temporal operation done by the ``@'' is the one defined in the field definition: 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 )'': 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.
697
698(7) use of the ``@'' function: example 3, monthly average of SST diurnal cycle
699
700 - define 2 new variables in field\_definition
701\vspace{-20pt}
702\begin{xmlcode}
703 <field id="sstmax" field\_ref="sst" long\_name="max of sea surface temperature" operation="maximum" />
704 <field id="sstmin" field\_ref="sst" long\_name="min of sea surface temperature" operation="minimum" />
705\end{xmlcode}
706 - use these 2 new variables when defining your file. 
707\vspace{-20pt}
708\begin{xmlcode}
709<file\_group id="1m" output\_freq="1m"  output\_level="10" enabled=".TRUE." >  <!-- 1m files --> 
710 <file id="file1" name\_suffix="\_grid\_T" description="ocean T grid variables" >
711  <field field\_ref="sst" name="sstdcy" long\_name="amplitude of sst diurnal cycle" operation="average" freq\_op="1d" > @sstmax - @sstmin </field>
712 </file>
713</file\_group>
714\end{xmlcode}
715The freq\_op="1d" attribute is used to define the operation frequency of the ``@'' function: here 1 day. The temporal operation done by the ``@'' is the one defined in the field definition: here maximum for sstmax and minimum for sstmin. So, in the above case, @sstmax will do the daily max and @sstmin the daily min. Operation="average" refers to the temporal operation to be performed on the field ``@sstmax - @sstmin'': here monthly mean (of daily max - daily min of the sst). field\_ref="sst" means that attributes not explicitely defined, are inherited from sst field.
716
717
718
719\subsubsection{Tag list}
720
721\begin{longtable}{|p{2.2cm}|p{2.5cm}|p{3.5cm}|p{2.2cm}|p{1.6cm}|}
722   \hline
723   tag name & 
724   description & 
725   accepted attribute & 
726   child of &
727   parent of \endhead
728   \hline   
729   simulation & 
730   this tag is the root tag which encapsulates all the content of the xml file &
731   none &
732   none &
733   context \\
734   \hline   
735   context &
736   encapsulates parts of the xml file dedicated to different codes or different parts of a code &
737   id (''xios'', ''nemo'' or ''n\_nemo'' for the nth AGRIF zoom), src, time\_origin &
738   simulation &
739   all root tags: ... \_definition \\
740   \hline   
741   \hline   
742   field\_definition &
743   encapsulates the definition of all the fields that can potentially be outputted &
744   axis\_ref, default\_value, domain\_ref, enabled, grid\_ref, level, operation, prec, src &
745   context &
746   field or field\_group \\
747   \hline   
748   field\_group &
749   encapsulates a group of fields &
750   axis\_ref, default\_value, domain\_ref, enabled, group\_ref, grid\_ref, id, level, operation, prec, src &
751   field\_definition, field\_group, file &
752   field or field\_group \\
753   \hline   
754   field &
755   define a specific field &
756   axis\_ref, default\_value, domain\_ref, enabled, field\_ref, grid\_ref, id, level, long\_name, name, operation, prec, standard\_name, unit &
757   field\_definition, field\_group, file &
758   none \\
759   \hline   
760   \hline   
761   file\_definition & 
762   encapsulates the definition of all the files that will be outputted &
763   enabled, min\_digits, name, name\_suffix, output\_level, split\_freq\_format, split\_freq, sync\_freq, type, src &
764   context & 
765   file or file\_group \\
766   \hline   
767   file\_group & 
768   encapsulates a group of files that will be outputted &
769   enabled, description, id, min\_digits, name, name\_suffix, output\_freq, output\_level, split\_freq\_format, split\_freq, sync\_freq, type, src &
770   file\_definition, file\_group & 
771   file or file\_group \\
772   \hline   
773   file & 
774   define the contents of a file to be outputted &
775   enabled, description, id, min\_digits, name, name\_suffix, output\_freq, output\_level, split\_freq\_format, split\_freq, sync\_freq, type, src &
776   file\_definition, file\_group & 
777   field \\
778   \hline   
779   axis\_definition & 
780   define all the vertical axis potentially used by the variables &
781   src &
782   context & 
783   axis\_group, axis \\
784   \hline   
785   axis\_group & 
786   encapsulates a group of vertical axis &
787   id, lon\_name, positive, src, standard\_name, unit, zoom\_begin, zoom\_end, zoom\_size &
788   axis\_definition, axis\_group & 
789   axis\_group, axis \\
790   \hline   
791   axis & 
792   define a vertical axis &
793   id, lon\_name, positive, src, standard\_name, unit, zoom\_begin, zoom\_end, zoom\_size &
794   axis\_definition, axis\_group  & 
795   none \\
796   \hline   
797   \hline   
798   domain\_\-definition & 
799   define all the horizontal domains potentially used by the variables &
800   src &
801   context & 
802   domain\_\-group, domain \\
803   \hline   
804   domain\_group & 
805   encapsulates a group of horizontal domains &
806   id, lon\_name, src, zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj &
807   domain\_\-definition, domain\_group & 
808   domain\_\-group, domain \\
809   \hline   
810   domain & 
811   define an horizontal domain &
812   id, lon\_name, src, zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj &
813   domain\_\-definition, domain\_group & 
814   none \\
815   \hline   
816   \hline   
817   grid\_definition & 
818   define all the grid (association of a domain and/or an axis) potentially used by the variables &
819   src &
820   context & 
821   grid\_group, grid \\
822   \hline   
823   grid\_group & 
824   encapsulates a group of grids &
825   id, domain\_ref, axis\_ref &
826   grid\_definition, grid\_group & 
827   grid\_group, grid \\
828   \hline   
829   grid & 
830   define a grid &
831   id, domain\_ref, axis\_ref &
832   grid\_definition, grid\_group & 
833   none \\
834   \hline   
835\end{longtable}
836
837
838\subsubsection{Attributes list}
839
840\begin{longtable}{|p{2.2cm}|p{4cm}|p{3.8cm}|p{2cm}|}
841   \hline
842   attribute name & 
843   description & 
844   example & 
845   accepted by \endhead
846   \hline   
847   axis\_ref & 
848   refers to the id of a vertical axis & 
849   axis\_ref="deptht" & 
850   field, grid families \\ 
851   \hline   
852   enabled & 
853   switch on/off the output of a field or a file & 
854   enabled=".TRUE." & 
855   field, file families \\ 
856   \hline   
857   default\_value & 
858   missing\_value definition & 
859   default\_value="1.e20" & 
860   field family \\ 
861   \hline   
862   description & 
863   just for information, not used & 
864   description="ocean T grid variables" & 
865   all tags \\ 
866   \hline   
867   domain\_ref & 
868   refers to the id of a domain & 
869   domain\_ref="grid\_T" & 
870   field or grid families \\ 
871   \hline   
872   field\_ref & 
873   id of the field we want to add in a file & 
874   field\_ref="toce" & 
875   field \\ 
876   \hline   
877   grid\_ref & 
878   refers to the id of a grid & 
879   grid\_ref="grid\_T\_2D" & 
880   field family \\ 
881   \hline   
882   group\_ref & 
883   refer to a group of variables & 
884   group\_ref="mooring" & 
885   field\_group \\ 
886   \hline   
887   id & 
888   allow to identify a tag & 
889   id="nemo" &
890   accepted by all tags except simulation \\ 
891   \hline   
892   level & 
893   output priority of a field: 0 (high) to 10 (low)& 
894   level="1" & 
895   field family \\ 
896   \hline   
897   long\_name & 
898   define the long\_name attribute in the NetCDF file & 
899   long\_name="Vertical T levels" & 
900   field \\ 
901   \hline   
902   min\_digits & 
903   specify the minimum of digits used in the core number in the name of the NetCDF file & 
904   min\_digits="4" & 
905   file family \\ 
906   \hline   
907   name & 
908   name of a variable or a file. If the name of a file is undefined, its id is used as a name & 
909   name="tos" & 
910   field or file families \\ 
911   \hline   
912   name\_suffix & 
913   suffix to be inserted after the name and before the cpu number and the ''.nc'' termination of a file & 
914   name\_suffix="\_myzoom" & 
915   file family \\ 
916   \hline   
917   attribute name & 
918   description & 
919   example & 
920   accepted by \\ 
921   \hline   
922   \hline   
923   operation & 
924   type of temporal operation: average, accumulate, instantaneous, min, max and once & 
925   operation="average" & 
926   field family \\ 
927   \hline   
928   output\_freq & 
929   operation frequency. units can be ts (timestep), y, mo, d, h, mi, s. & 
930   output\_freq="1d12h" & 
931   field family \\ 
932   \hline   
933   output\_level & 
934   output priority of variables in a file: 0 (high) to 10 (low). All variables listed in the file with a level smaller or equal to output\_level will be output. Other variables won't be output even if they are listed in the file. & 
935   output\_level="10"& 
936   file family \\ 
937   \hline   
938   positive & 
939   convention used for the orientation of vertival axis (positive downward in \NEMO). & 
940   positive="down" & 
941   axis family \\ 
942   \hline   
943   prec & 
944   output precision: real 4 or real 8 & 
945   prec="4" & 
946   field family \\ 
947   \hline   
948   split\_freq & 
949   frequency at which to temporally split output files. Units can be ts (timestep), y, mo, d, h, mi, s. Useful for long runs to prevent over-sized output files.& 
950   split\_freq="1mo" & 
951   file family \\ 
952   \hline   
953   split\_freq\-\_format & 
954   date format used in the name of temporally split output files. Can be specified
955   using the following syntaxes: \%y, \%mo, \%d, \%h \%mi and \%s & 
956   split\_freq\_format= "\%y\%mo\%d" & 
957   file family \\ 
958   \hline   
959   src & 
960   allow to include a file & 
961   src="./field\_def.xml" & 
962   accepted by all tags except simulation \\ 
963   \hline   
964   standard\_name & 
965   define the standard\_name attribute in the NetCDF file & 
966   standard\_name= "Eastward\_Sea\_Ice\_Transport" & 
967   field \\ 
968   \hline   
969   sync\_freq & 
970   NetCDF file synchronization frequency (update of the time\_counter). units can be ts (timestep), y, mo, d, h, mi, s. & 
971   sync\_freq="10d" & 
972   file family \\ 
973   \hline   
974   attribute name & 
975   description & 
976   example & 
977   accepted by \\ 
978   \hline   
979   \hline   
980   time\_origin & 
981   specify the origin of the time counter & 
982   time\_origin="1900-01-01 00:00:00"& 
983   context \\ 
984   \hline   
985   type (1)& 
986   specify if the output files are to be split spatially (multiple\_file) or not (one\_file) & 
987   type="multiple\_file" & 
988   file familly \\ 
989   \hline   
990   type (2)& 
991   define the type of a variable tag & 
992   type="boolean" & 
993   variable \\ 
994   \hline   
995   unit & 
996   unit of a variable or the vertical axis & 
997   unit="m" & 
998   field and axis families \\ 
999   \hline   
1000   zoom\_ibegin & 
1001   starting point along x direction of the zoom. Automatically defined for TAO/RAMA/PIRATA moorings & 
1002   zoom\_ibegin="1" & 
1003   domain family \\ 
1004   \hline   
1005   zoom\_jbegin & 
1006   starting point along y direction of the zoom. Automatically defined for TAO/RAMA/PIRATA moorings & 
1007   zoom\_jbegin="1" & 
1008   domain family \\ 
1009   \hline   
1010   zoom\_ni & 
1011   zoom extent along x direction & 
1012   zoom\_ni="1" & 
1013   domain family \\ 
1014   \hline   
1015   zoom\_nj & 
1016   zoom extent along y direction & 
1017   zoom\_nj="1" & 
1018   domain family \\ 
1019   \hline   
1020\end{longtable}
1021
1022\subsection{CF metadata standard compliance}
1023
1024Output from the XIOS-1.0 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. Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of section \ref{IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard.
1025
1026Some 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. This must be set to true if these metadata are to be included in the output files.
1027
1028
1029% ================================================================
1030%       NetCDF4 support
1031% ================================================================
1032\section{NetCDF4 Support (\protect\key{netcdf4})}
1033\label{DIA_iom}
1034
1035Since version 3.3, support for NetCDF4 chunking and (loss-less) compression has
1036been included.  These options build on the standard NetCDF output and allow
1037the user control over the size of the chunks via namelist settings. Chunking
1038and compression can lead to significant reductions in file sizes for a small
1039runtime overhead. For a fuller discussion on chunking and other performance
1040issues the reader is referred to the NetCDF4 documentation found
1041\href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}.
1042
1043The new features are only available when the code has been linked with a
1044NetCDF4 library (version 4.1 onwards, recommended) which has been built
1045with HDF5 support (version 1.8.4 onwards, recommended). Datasets created
1046with chunking and compression are not backwards compatible with NetCDF3
1047"classic" format but most analysis codes can be relinked simply with the
1048new libraries and will then read both NetCDF3 and NetCDF4 files. NEMO
1049executables linked with NetCDF4 libraries can be made to produce NetCDF3
1050files by setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} 
1051namelist:
1052
1053%------------------------------------------namnc4----------------------------------------------------
1054\fortranfile{namelists/namnc4}
1055%-------------------------------------------------------------------------------------------------------------
1056
1057If \key{netcdf4} has not been defined, these namelist parameters are not read.
1058In this case, \np{ln\_nc4zip} is set false and dummy routines for a few
1059NetCDF4-specific functions are defined. These functions will not be used but
1060need to be included so that compilation is possible with NetCDF3 libraries.
1061
1062When using NetCDF4 libraries, \key{netcdf4} should be defined even if the
1063intention is to create only NetCDF3-compatible files. This is necessary to
1064avoid duplication between the dummy routines and the actual routines present
1065in the library. Most compilers will fail at compile time when faced with
1066such duplication. Thus when linking with NetCDF4 libraries the user must
1067define \key{netcdf4} and control the type of NetCDF file produced via the
1068namelist parameter.
1069
1070Chunking and compression is applied only to 4D fields and there is no
1071advantage in chunking across more than one time dimension since previously
1072written chunks would have to be read back and decompressed before being
1073added to. Therefore, user control over chunk sizes is provided only for the
1074three space dimensions. The user sets an approximate number of chunks along
1075each spatial axis. The actual size of the chunks will depend on global domain
1076size for mono-processors or, more likely, the local processor domain size for
1077distributed processing. The derived values are subject to practical minimum
1078values (to avoid wastefully small chunk sizes) and cannot be greater than the
1079domain size in any dimension. The algorithm used is:
1080
1081\vspace{-20pt}
1082\begin{fortrancode}
1083     ichunksz(1) = MIN( idomain_size,MAX( (idomain_size-1)/nn_nchunks_i + 1 ,16 ) )
1084     ichunksz(2) = MIN( jdomain_size,MAX( (jdomain_size-1)/nn_nchunks_j + 1 ,16 ) )
1085     ichunksz(3) = MIN( kdomain_size,MAX( (kdomain_size-1)/nn_nchunks_k + 1 , 1 ) )
1086     ichunksz(4) = 1
1087\end{fortrancode}
1088
1089\noindent As an example, setting:
1090\vspace{-20pt}
1091\begin{fortrancode}
1092     nn_nchunks_i=4, nn_nchunks_j=4 and nn_nchunks_k=31
1093\end{fortrancode}
1094
1095\noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\tt 46x38x1}
1096respectively in the mono-processor case (i.e. global domain of {\small\tt 182x149x31}).
1097An illustration of the potential space savings that NetCDF4 chunking and compression
1098provides is given in table \ref{Tab_NC4} which compares the results of two short
1099runs of the ORCA2\_LIM reference configuration with a 4x2 mpi partitioning. Note
1100the variation in the compression ratio achieved which reflects chiefly the dry to wet
1101volume ratio of each processing region.
1102
1103%------------------------------------------TABLE----------------------------------------------------
1104\begin{table}  \begin{tabular}{lrrr}
1105Filename & NetCDF3 & NetCDF4 & Reduction\\
1106         &filesize & filesize & \% \\
1107         &(KB)     & (KB)     & \\
1108ORCA2\_restart\_0000.nc & 16420 & 8860 & 47\%\\
1109ORCA2\_restart\_0001.nc & 16064 & 11456 & 29\%\\
1110ORCA2\_restart\_0002.nc & 16064 & 9744 & 40\%\\
1111ORCA2\_restart\_0003.nc & 16420 & 9404 & 43\%\\
1112ORCA2\_restart\_0004.nc & 16200 & 5844 & 64\%\\
1113ORCA2\_restart\_0005.nc & 15848 & 8172 & 49\%\\
1114ORCA2\_restart\_0006.nc & 15848 & 8012 & 50\%\\
1115ORCA2\_restart\_0007.nc & 16200 & 5148 & 69\%\\
1116ORCA2\_2d\_grid\_T\_0000.nc & 2200 & 1504 & 32\%\\
1117ORCA2\_2d\_grid\_T\_0001.nc & 2200 & 1748 & 21\%\\
1118ORCA2\_2d\_grid\_T\_0002.nc & 2200 & 1592 & 28\%\\
1119ORCA2\_2d\_grid\_T\_0003.nc & 2200 & 1540 & 30\%\\
1120ORCA2\_2d\_grid\_T\_0004.nc & 2200 & 1204 & 46\%\\
1121ORCA2\_2d\_grid\_T\_0005.nc & 2200 & 1444 & 35\%\\
1122ORCA2\_2d\_grid\_T\_0006.nc & 2200 & 1428 & 36\%\\
1123ORCA2\_2d\_grid\_T\_0007.nc & 2200 & 1148 & 48\%\\
1124             ...            &  ... &  ... & ..  \\
1125ORCA2\_2d\_grid\_W\_0000.nc & 4416 & 2240 & 50\%\\
1126ORCA2\_2d\_grid\_W\_0001.nc & 4416 & 2924 & 34\%\\
1127ORCA2\_2d\_grid\_W\_0002.nc & 4416 & 2512 & 44\%\\
1128ORCA2\_2d\_grid\_W\_0003.nc & 4416 & 2368 & 47\%\\
1129ORCA2\_2d\_grid\_W\_0004.nc & 4416 & 1432 & 68\%\\
1130ORCA2\_2d\_grid\_W\_0005.nc & 4416 & 1972 & 56\%\\
1131ORCA2\_2d\_grid\_W\_0006.nc & 4416 & 2028 & 55\%\\
1132ORCA2\_2d\_grid\_W\_0007.nc & 4416 & 1368 & 70\%\\
1133\end{tabular}
1134\caption{   \protect\label{Tab_NC4} 
1135Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression}
1136\end{table}
1137%----------------------------------------------------------------------------------------------------
1138
1139When \key{iomput} is activated with \key{netcdf4} chunking and
1140compression parameters for fields produced via \np{iom\_put} calls are
1141set via an equivalent and identically named namelist to \textit{namnc4} 
1142in \np{xmlio\_server.def}. Typically this namelist serves the mean files
1143whilst the \ngn{ namnc4} in the main namelist file continues to serve the
1144restart files. This duplication is unfortunate but appropriate since, if
1145using io\_servers, the domain sizes of the individual files produced by the
1146io\_server processes may be different to those produced by the invidual
1147processing regions and different chunking choices may be desired.
1148 
1149
1150% -------------------------------------------------------------------------------------------------------------
1151%       Tracer/Dynamics Trends
1152% -------------------------------------------------------------------------------------------------------------
1153\section[Tracer/Dynamics Trends (TRD)]
1154                  {Tracer/Dynamics Trends  (\protect\ngn{namtrd})}
1155\label{DIA_trd}
1156
1157%------------------------------------------namtrd----------------------------------------------------
1158\fortranfile{namelists/namtrd} 
1159%-------------------------------------------------------------------------------------------------------------
1160
1161Each trend of the dynamics and/or temperature and salinity time evolution equations
1162can be send to \mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation
1163($i.e.$ at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines).
1164This capability is controlled by options offered in \ngn{namtrd} namelist.
1165Note that the output are done with xIOS, and therefore the \key{IOM} is required.
1166
1167What is done depends on the \ngn{namtrd} logical set to \textit{true}:
1168\begin{description}
1169\item[\np{ln\_glo\_trd}] : at each \np{nn\_trd} time-step a check of the basin averaged properties
1170of the momentum and tracer equations is performed. This also includes a check of $T^2$, $S^2$,
1171$\tfrac{1}{2} (u^2+v2)$, and potential energy time evolution equations properties ;
1172\item[\np{ln\_dyn\_trd}] : each 3D trend of the evolution of the two momentum components is output ;
1173\item[\np{ln\_dyn\_mxl}] : each 3D trend of the evolution of the two momentum components averaged
1174                           over the mixed layer is output  ;
1175\item[\np{ln\_vor\_trd}] : a vertical summation of the moment tendencies is performed,
1176                           then the curl is computed to obtain the barotropic vorticity tendencies which are output ;
1177\item[\np{ln\_KE\_trd}]  : each 3D trend of the Kinetic Energy equation is output ;
1178\item[\np{ln\_tra\_trd}] : each 3D trend of the evolution of temperature and salinity is output ;
1179\item[\np{ln\_tra\_mxl}] : each 2D trend of the evolution of temperature and salinity averaged
1180                           over the mixed layer is output ;
1181\end{description}
1182
1183Note that the mixed layer tendency diagnostic can also be used on biogeochemical models
1184via the \key{trdtrc} and \key{trdmld\_trc} CPP keys.
1185
1186\textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested.
1187In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} 
1188are not working, and none of the option have been tested with variable volume ($i.e.$ \key{vvl} defined).
1189
1190
1191% -------------------------------------------------------------------------------------------------------------
1192%       On-line Floats trajectories
1193% -------------------------------------------------------------------------------------------------------------
1194\section{On-line Floats trajectories (FLO) (\protect\key{floats})}
1195\label{FLO}
1196%--------------------------------------------namflo-------------------------------------------------------
1197\fortranfile{namelists/namflo} 
1198%--------------------------------------------------------------------------------------------------------------
1199
1200The on-line computation of floats advected either by the three dimensional velocity
1201field or constraint to remain at a given depth ($w = 0$ in the computation) have been
1202introduced in the system during the CLIPPER project. Options are defined by \ngn{namflo}
1203namelis variables. The algorithm used is based
1204either on the work of \cite{Blanke_Raynaud_JPO97} (default option), or on a $4^th$
1205Runge-Hutta algorithm (\np{ln\_flork4}=true). Note that the \cite{Blanke_Raynaud_JPO97} 
1206algorithm have the advantage of providing trajectories which are consistent with the
1207numeric of the code, so that the trajectories never intercept the bathymetry.
1208
1209\subsubsection{ Input data: initial coordinates }
1210
1211Initial coordinates can be given with Ariane Tools convention ( IJK coordinates ,(\np{ln\_ariane}=true) )
1212or with longitude and latitude.
1213
1214
1215In case of Ariane convention, input filename is \np{init\_float\_ariane}. Its format is:
1216
1217\texttt{ I J K nisobfl itrash itrash }
1218
1219\noindent with:
1220
1221 - I,J,K  : indexes of initial position
1222
1223 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity 
1224
1225 - itrash : set to zero; it is a dummy variable to respect Ariane Tools convention
1226
1227 - itrash :set to zero; it is a dummy variable to respect Ariane Tools convention
1228
1229\noindent Example:\\
1230\noindent \texttt{ 100.00000  90.00000  -1.50000 1.00000   0.00000}\\
1231\texttt{ 102.00000  90.00000  -1.50000 1.00000   0.00000}\\
1232\texttt{ 104.00000  90.00000  -1.50000 1.00000   0.00000}\\
1233\texttt{ 106.00000  90.00000  -1.50000 1.00000   0.00000}\\
1234\texttt{ 108.00000  90.00000  -1.50000 1.00000   0.00000}\\
1235
1236
1237In the other case ( longitude and latitude ), input filename is init\_float. Its format is:
1238
1239\texttt{ Long Lat depth nisobfl ngrpfl itrash}
1240
1241\noindent with:
1242
1243 - Long, Lat, depth  : Longitude, latitude, depth
1244
1245 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity
1246
1247 - ngrpfl : number to identify searcher group
1248
1249 - itrash :set to 1; it is a dummy variable.
1250
1251\noindent Example:
1252
1253\noindent\texttt{  20.0 0.0 0.0 0 1 1 }\\
1254\texttt{ -21.0 0.0 0.0 0 1 1 }\\
1255\texttt{ -22.0 0.0 0.0 0 1 1 }\\
1256\texttt{ -23.0 0.0 0.0 0 1 1 }\\
1257\texttt{ -24.0 0.0 0.0 0 1 1 }\\
1258
1259\np{jpnfl} is the total number of floats during the run.
1260When initial positions are read in a restart file ( \np{ln\_rstflo}= .TRUE. ),  \np{jpnflnewflo}
1261can be added in the initialization file.
1262
1263\subsubsection{ Output data }
1264
1265\np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} 
1266is the frequency of creation of the float restart file.
1267
1268Output data can be written in ascii files (\np{ln\_flo\_ascii} = .TRUE. ). In that case,
1269output filename is trajec\_float.
1270
1271Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii} = .FALSE. ). There are 2 possibilities:
1272
1273 - if (\key{iomput}) is used, outputs are selected in  iodef.xml. Here it is an example of specification
1274   to put in files description section:
1275
1276\vspace{-30pt}
1277\begin{xmlcode}
1278     <group id="1d\_grid\_T" name="auto" description="ocean T grid variables" >   }
1279       <file id="floats"  description="floats variables"> }\\
1280           <field ref="traj\_lon"   name="floats\_longitude"   freq\_op="86400" />}
1281           <field ref="traj\_lat"   name="floats\_latitude"    freq\_op="86400" />}
1282           <field ref="traj\_dep"   name="floats\_depth"       freq\_op="86400" />}
1283           <field ref="traj\_temp"  name="floats\_temperature" freq\_op="86400" />}
1284           <field ref="traj\_salt"  name="floats\_salinity"    freq\_op="86400" />}
1285           <field ref="traj\_dens"  name="floats\_density"     freq\_op="86400" />}
1286           <field ref="traj\_group" name="floats\_group"       freq\_op="86400" />}
1287       </file>}
1288  </group>}
1289\end{xmlcode}
1290
1291
1292 -  if (\key{iomput}) is not used, a file called trajec\_float.nc will be created by IOIPSL library.
1293
1294
1295
1296See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing
1297the off-line use of this marvellous diagnostic tool.
1298
1299
1300% -------------------------------------------------------------------------------------------------------------
1301%       Harmonic analysis of tidal constituents
1302% -------------------------------------------------------------------------------------------------------------
1303\section{Harmonic analysis of tidal constituents (\protect\key{diaharm}) }
1304\label{DIA_diag_harm}
1305
1306%------------------------------------------namdia_harm----------------------------------------------------
1307%\fortranfile{namelists/namdia_harm}
1308%----------------------------------------------------------------------------------------------------------
1309
1310A module is available to compute the amplitude and phase of tidal waves.
1311This on-line Harmonic analysis is actived with \key{diaharm}.
1312Some parameters are available in namelist \ngn{namdia\_harm} :
1313
1314- \np{nit000\_han} is the first time step used for harmonic analysis
1315
1316- \np{nitend\_han} is the last time step used for harmonic analysis
1317
1318- \np{nstep\_han} is the time step frequency for harmonic analysis
1319
1320- \np{nb\_ana} is the number of harmonics to analyse
1321
1322- \np{tname} is an array with names of tidal constituents to analyse
1323
1324\np{nit000\_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation.
1325The restart capability is not implemented.
1326
1327The Harmonic analysis solve the following equation:
1328\begin{equation}
1329h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[A_{j}cos(\nu_{j}t_{j}-\phi_{j})] = e_{i}
1330\end{equation}
1331
1332With $A_{j}$,$\nu_{j}$,$\phi_{j}$, the amplitude, frequency and phase for each wave and $e_{i}$ the error.
1333$h_{i}$ is the sea level for the time $t_{i}$ and $A_{0}$ is the mean sea level. \\
1334We can rewrite this equation:
1335\begin{equation}
1336h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[C_{j}cos(\nu_{j}t_{j})+S_{j}sin(\nu_{j}t_{j})] = e_{i}
1337\end{equation}
1338with $A_{j}=\sqrt{C^{2}_{j}+S^{2}_{j}}$ et $\phi_{j}=arctan(S_{j}/C_{j})$.
1339
1340We obtain in output $C_{j}$ and $S_{j}$ for each tidal wave.
1341
1342% -------------------------------------------------------------------------------------------------------------
1343%       Sections transports
1344% -------------------------------------------------------------------------------------------------------------
1345\section{Transports across sections (\protect\key{diadct}) }
1346\label{DIA_diag_dct}
1347
1348%------------------------------------------namdct----------------------------------------------------
1349\fortranfile{namelists/namdct}
1350%-------------------------------------------------------------------------------------------------------------
1351
1352A module is available to compute the transport of volume, heat and salt through sections.
1353This diagnostic is actived with \key{diadct}.
1354
1355Each section is defined by the coordinates of its 2 extremities. The pathways between them are contructed
1356using tools which can be found in  \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT} and are written in a binary file
1357 \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by NEMO to compute on-line transports.
1358
1359The on-line transports module creates three output ascii files:
1360
1361- \texttt{volume\_transport} for volume transports (  unit: $10^{6} m^{3} s^{-1}$ )
1362
1363- \texttt{heat\_transport}   for heat transports   (  unit: $10^{15} W $ )
1364
1365- \texttt{salt\_transport}   for salt transports   (  unit: $10^{9}Kg s^{-1}$ )\\
1366
1367
1368Namelist variables in \ngn{namdct} control how frequently the flows are summed
1369and the time scales over which they are averaged, as well as the level of output for debugging:
1370
1371\np{nn\_dct}: frequency of instantaneous transports computing
1372
1373\np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports )
1374
1375\np{nn\_debug}: debugging of the section
1376
1377\subsubsection{ Creating a binary file containing the pathway of each section }
1378
1379In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run}, the file \textit{ {list\_sections.ascii\_global}}
1380contains a list of all the sections that are to be computed (this list of sections is based on MERSEA project metrics).
1381
1382Another file is available for the GYRE configuration (\texttt{ {list\_sections.ascii\_GYRE}}).
1383
1384Each section is defined by:
1385
1386\noindent \texttt{ long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name }\\
1387with:
1388
1389- \texttt{long1 lat1} , coordinates of the first extremity of the section;
1390
1391- \texttt{long2 lat2} , coordinates of the second extremity of the section;
1392
1393- \texttt{nclass} the number of bounds of your classes (e.g. 3 bounds for 2 classes);
1394
1395- \texttt{okstrpond} to compute heat and salt transport, \texttt{nostrpond} if no;
1396
1397- \texttt{ice}  to compute surface and volume ice transports, \texttt{noice} if no. \\
1398
1399
1400\noindent The results of the computing of transports, and the directions of positive
1401 and negative flow do not depend on the order of the 2 extremities in this file.\\ 
1402
1403
1404\noindent If nclass =/ 0,the next lines contain the class type and the nclass bounds:
1405
1406\texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}
1407
1408\texttt{classtype}
1409
1410\texttt{zbound1}
1411
1412\texttt{zbound2}
1413
1414\texttt{.}
1415
1416\texttt{.}
1417
1418\texttt{nclass-1}
1419
1420\texttt{nclass}
1421
1422\noindent where \texttt{classtype} can be:
1423
1424- \texttt{zsal} for salinity classes
1425
1426- \texttt{ztem} for temperature classes
1427
1428- \texttt{zlay} for depth classes
1429
1430- \texttt{zsigi} for insitu density classes
1431
1432- \texttt{zsigp} for potential density classes \\
1433
1434 
1435The script \texttt{job.ksh} computes the pathway for each section and creates a binary file
1436\texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\
1437
1438It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated
1439with the coordinates file name and path. \\
1440
1441
1442Examples of two sections, the ACC\_Drake\_Passage with no classes, and the
1443 ATL\_Cuba\_Florida with 4 temperature clases (5 class bounds), are shown:
1444
1445\noindent \texttt{ -68.    -54.5   -60.    -64.7  00 okstrpond noice ACC\_Drake\_Passage}
1446
1447\noindent \texttt{ -80.5    22.5   -80.5    25.5  05 nostrpond noice ATL\_Cuba\_Florida}
1448
1449\noindent \texttt{ztem}
1450
1451\noindent \texttt{-2.0}
1452
1453\noindent \texttt{ 4.5}
1454
1455\noindent \texttt{ 7.0}
1456
1457\noindent \texttt{12.0}
1458
1459\noindent \texttt{40.0}
1460
1461
1462\subsubsection{ To read the output files }
1463
1464The output format is :
1465 
1466{\small\texttt{date, time-step number, section number, section name, section slope coefficient, class number,
1467class name, class bound 1 , classe bound2, transport\_direction1 ,  transport\_direction2, transport\_total}}\\
1468
1469
1470For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for each class
1471and the last line corresponds to the total transport summed over all classes. For sections with no classes, class number
1472\texttt{ 1 } corresponds to \texttt{ total class } and this class is called  \texttt{N}, meaning \texttt{none}.\\
1473
1474
1475\noindent \texttt{ transport\_direction1 } is the positive part of the transport ( \texttt{ > = 0 } ).
1476
1477\noindent \texttt{ transport\_direction2 } is the negative part of the transport ( \texttt{ < = 0 } ).\\
1478
1479
1480\noindent The \texttt{section slope coefficient} gives information about the significance of transports signs and direction:\\
1481
1482
1483
1484\begin{tabular}{|c|c|c|c|p{4cm}|}
1485\hline
1486section slope coefficient & section type & direction 1 & direction 2 & total transport \\ \hline
14870.    &  horizontal & northward & southward & postive: northward  \\ \hline
14881000. &  vertical   & eastward  & westward  & postive: eastward  \\ \hline               
1489\texttt{=/0, =/ 1000.}   &  diagonal   & eastward  & westward  & postive: eastward  \\ \hline               
1490\end{tabular}
1491
1492
1493% ================================================================
1494% Steric effect in sea surface height
1495% ================================================================
1496\section{Diagnosing the Steric effect in sea surface height}
1497\label{DIA_steric}
1498
1499
1500Changes in steric sea level are caused when changes in the density of the water
1501column imply an expansion or contraction of the column. It is essentially produced
1502through surface heating/cooling and to a lesser extent through non-linear effects of
1503the equation of state (cabbeling, thermobaricity...).
1504Non-Boussinesq models contain all ocean effects within the ocean acting
1505on the sea level. In particular, they include the steric effect. In contrast,
1506Boussinesq models, such as \NEMO, conserve volume, rather than mass,
1507and so do not properly represent expansion or contraction. The steric effect is
1508therefore not explicitely represented.
1509This approximation does not represent a serious error with respect to the flow field
1510calculated by the model \citep{Greatbatch_JGR94}, but extra attention is required
1511when investigating sea level, as steric changes are an important
1512contribution to local changes in sea level on seasonal and climatic time scales.
1513This is especially true for investigation into sea level rise due to global warming.
1514
1515Fortunately, the steric contribution to the sea level consists of a spatially uniform
1516component that can be diagnosed by considering the mass budget of the world
1517ocean \citep{Greatbatch_JGR94}.
1518In order to better understand how global mean sea level evolves and thus how
1519the steric sea level can be diagnosed, we compare, in the following, the
1520non-Boussinesq and Boussinesq cases.
1521
1522Let denote
1523$\mathcal{M}$ the total mass of liquid seawater ($\mathcal{M}=\int_D \rho dv$),
1524$\mathcal{V}$ the total volume of seawater ($\mathcal{V}=\int_D dv$),
1525$\mathcal{A}$ the total surface of the ocean ($\mathcal{A}=\int_S ds$),
1526$\bar{\rho}$ the global mean seawater (\textit{in situ}) density ($\bar{\rho}= 1/\mathcal{V} \int_D \rho \,dv$), and
1527$\bar{\eta}$ the global mean sea level ($\bar{\eta}=1/\mathcal{A}\int_S \eta \,ds$).
1528
1529A non-Boussinesq fluid conserves mass. It satisfies the following relations:
1530\begin{equation} \label{Eq_MV_nBq} 
1531\begin{split} 
1532\mathcal{M} &\mathcal{V}  \;\bar{\rho}       \\
1533\mathcal{V} &\mathcal{A}  \;\bar{\eta} 
1534\end{split}
1535\end{equation}
1536Temporal changes in total mass is obtained from the density conservation equation :
1537\begin{equation}  \label{Eq_Co_nBq}
1538\frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} ) = \left. \frac{\textit{emp}}{e_3}\right|_\textit{surface}
1539\end{equation}
1540where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass
1541exchanges with the other media of the Earth system (atmosphere, sea-ice, land).
1542Its global averaged leads to the total mass change
1543\begin{equation}  \label{Eq_Mass_nBq}
1544\partial_t \mathcal{M} = \mathcal{A} \;\overline{\textit{emp}}
1545\end{equation}
1546where $\overline{\textit{emp}}=\int_S \textit{emp}\,ds$ is the net mass flux
1547through the ocean surface.
1548Bringing \eqref{Eq_Mass_nBq} and the time derivative of \eqref{Eq_MV_nBq} 
1549together leads to the evolution equation of the mean sea level
1550\begin{equation} \label{Eq_ssh_nBq}
1551  \partial_t \bar{\eta} =  \frac{\overline{\textit{emp}}}{ \bar{\rho}} 
1552               - \frac{\mathcal{V}}{\mathcal{A}}  \;\frac{\partial_t \bar{\rho} }{\bar{\rho}}
1553\end{equation}
1554The first term in equation \eqref{Eq_ssh_nBq} alters sea level by adding or
1555subtracting mass from the ocean.
1556The second term arises from temporal changes in the global mean
1557density; $i.e.$ from steric effects.
1558
1559In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ 
1560appears multiplied by the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations).
1561In particular, the mass conservation equation, \eqref{Eq_Co_nBq}, degenerates into
1562the incompressibility equation:
1563\begin{equation}  \label{Eq_Co_Bq}
1564\frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) =  \left. \frac{\textit{emp}}{\rho_o \,e_3}\right|_ \textit{surface}
1565\end{equation}
1566and the global average of this equation now gives the temporal change of the total volume,
1567\begin{equation}  \label{Eq_V_Bq}
1568  \partial_t \mathcal{V} =   \mathcal{A} \;\frac{\overline{\textit{emp}}}{\rho_o} 
1569\end{equation}
1570Only the volume is conserved, not mass, or, more precisely, the mass which is conserved is the
1571Boussinesq mass, $\mathcal{M}_o = \rho_o \mathcal{V}$. The total volume (or equivalently 
1572the global mean sea level) is altered only by net volume fluxes across the ocean surface, 
1573not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid.
1574 
1575Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be
1576diagnosed by considering the mass budget of the ocean.
1577The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface
1578mass flux must be compensated by a spatially uniform change in the mean sea level due to
1579expansion/contraction of the ocean \citep{Greatbatch_JGR94}. In others words, the Boussinesq
1580mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$, the  total mass of the ocean seen
1581by the Boussinesq model, via the steric contribution to the sea level, $\eta_s$, a spatially
1582uniform variable, as follows:
1583\begin{equation}  \label{Eq_M_Bq}
1584   \mathcal{M}_o  =  \mathcal{M} + \rho_o \,\eta_s \,\mathcal{A} 
1585\end{equation}
1586Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through
1587the ocean surface is converted into a mean change in sea level. Introducing the total density
1588anomaly, $\mathcal{D}= \int_D d_a \,dv$, where $d_a= (\rho -\rho_o ) / \rho_o$ 
1589is the density anomaly used in \NEMO (cf. \S\ref{TRA_eos}) in \eqref{Eq_M_Bq}
1590leads to a very simple form for the steric height:
1591\begin{equation}  \label{Eq_steric_Bq}
1592   \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D} 
1593\end{equation}
1594
1595The above formulation of the steric height of a Boussinesq ocean requires four remarks.
1596First, one can be tempted to define $\rho_o$ as the initial value of $\mathcal{M}/\mathcal{V}$,
1597$i.e.$ set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero. We do not
1598recommend that. Indeed, in this case $\rho_o$ depends on the initial state of the ocean.
1599Since $\rho_o$ has a direct effect on the dynamics of the ocean (it appears in the pressure
1600gradient term of the momentum equation) it is definitively not a good idea when
1601inter-comparing experiments.
1602We better recommend to fixe once for all $\rho_o$ to $1035\;Kg\,m^{-3}$. This value is a
1603sensible choice for the reference density used in a Boussinesq ocean climate model since,
1604with the exception of only a small percentage of the ocean, density in the World Ocean
1605varies by no more than 2$\%$ from this value (\cite{Gill1982}, page 47).
1606
1607Second, we have assumed here that the total ocean surface, $\mathcal{A}$, does not
1608change when the sea level is changing as it is the case in all global ocean GCMs
1609(wetting and drying of grid point is not allowed).
1610 
1611Third, the discretisation of \eqref{Eq_steric_Bq} depends on the type of free surface
1612which is considered. In the non linear free surface case, $i.e.$ \key{vvl} defined, it is
1613given by
1614\begin{equation}  \label{Eq_discrete_steric_Bq}
1615   \eta_s =  - \frac{ \sum_{i,\,j,\,k} d_a\; e_{1t} e_{2t} e_{3t} }
1616                  { \sum_{i,\,j,\,k}         e_{1t} e_{2t} e_{3t} } 
1617\end{equation}
1618whereas in the linear free surface, the volume above the \textit{z=0} surface must be explicitly taken
1619into account to better approximate the total ocean mass and thus the steric sea level:
1620\begin{equation}  \label{Eq_discrete_steric_Bq}
1621   \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 }
1622                     {\sum_{i,\,j,\,k} e_{1t}e_{2t}e_{3t} + \sum_{i,\,j}           e_{1t}e_{2t} \eta } 
1623\end{equation}
1624
1625The fourth and last remark concerns the effective sea level and the presence of sea-ice.
1626In the real ocean, sea ice (and snow above it)  depresses the liquid seawater through
1627its mass loading. This depression is a result of the mass of sea ice/snow system acting
1628on the liquid ocean. There is, however, no dynamical effect associated with these depressions
1629in the liquid ocean sea level, so that there are no associated ocean currents. Hence, the
1630dynamically relevant sea level is the effective sea level, $i.e.$ the sea level as if sea ice
1631(and snow) were converted to liquid seawater \citep{Campin_al_OM08}. However,
1632in the current version of \NEMO the sea-ice is levitating above the ocean without
1633mass exchanges between ice and ocean. Therefore the model effective sea level
1634is always given by $\eta + \eta_s$, whether or not there is sea ice present.
1635
1636In AR5 outputs, the thermosteric sea level is demanded. It is steric sea level due to
1637changes in ocean density arising just from changes in temperature. It is given by:
1638\begin{equation}  \label{Eq_thermosteric_Bq}
1639   \eta_s = - \frac{1}{\mathcal{A}} \int_D d_a(T,S_o,p_o) \,dv
1640\end{equation}
1641where $S_o$ and $p_o$ are the initial salinity and pressure, respectively.
1642
1643Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs
1644the \key{diaar5} defined to be called.
1645
1646
1647
1648% -------------------------------------------------------------------------------------------------------------
1649%       Other Diagnostics
1650% -------------------------------------------------------------------------------------------------------------
1651\section{Other Diagnostics (\protect\key{diahth}, \protect\key{diaar5})}
1652\label{DIA_diag_others}
1653
1654
1655Aside from the standard model variables, other diagnostics can be computed on-line.
1656The available ready-to-add diagnostics modules can be found in directory DIA.
1657
1658\subsection{Depth of various quantities (\protect\mdl{diahth})}
1659
1660Among the available diagnostics the following ones are obtained when defining
1661the \key{diahth} CPP key:
1662
1663- the mixed layer depth (based on a density criterion \citep{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth})
1664
1665- the turbocline depth (based on a turbulent mixing coefficient criterion) (\mdl{diahth})
1666
1667- the depth of the 20\deg C isotherm (\mdl{diahth})
1668
1669- the depth of the thermocline (maximum of the vertical temperature gradient) (\mdl{diahth})
1670
1671% -----------------------------------------------------------
1672%     Poleward heat and salt transports
1673% -----------------------------------------------------------
1674
1675\subsection{Poleward heat and salt transports (\protect\mdl{diaptr})}
1676
1677%------------------------------------------namptr-----------------------------------------
1678\fortranfile{namelists/namptr} 
1679%-----------------------------------------------------------------------------------------
1680
1681The poleward heat and salt transports, their advective and diffusive component, and
1682the meriodional stream function can be computed on-line in \mdl{diaptr} 
1683\np{ln\_diaptr} to true (see the \textit{\ngn{namptr} } namelist below). 
1684When \np{ln\_subbas}~=~true, transports and stream function are computed
1685for the Atlantic, Indian, Pacific and Indo-Pacific Oceans (defined north of 30\deg S)
1686as well as for the World Ocean. The sub-basin decomposition requires an input file
1687(\ifile{subbasins}) which contains three 2D mask arrays, the Indo-Pacific mask
1688been deduced from the sum of the Indian and Pacific mask (Fig~\ref{Fig_mask_subasins}).
1689
1690%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1691\begin{figure}[!t]     \begin{center}
1692\includegraphics[width=1.0\textwidth]{Fig_mask_subasins}
1693\caption{   \protect\label{Fig_mask_subasins}
1694Decomposition of the World Ocean (here ORCA2) into sub-basin used in to compute
1695the heat and salt transports as well as the meridional stream-function: Atlantic basin (red),
1696Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green).
1697Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay
1698are removed from the sub-basins. Note also that the Arctic Ocean has been split
1699into Atlantic and Pacific basins along the North fold line.  }
1700\end{center}   \end{figure} 
1701%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1702
1703
1704% -----------------------------------------------------------
1705%       CMIP specific diagnostics
1706% -----------------------------------------------------------
1707\subsection{CMIP specific diagnostics (\protect\mdl{diaar5})}
1708
1709A series of diagnostics has been added in the \mdl{diaar5}.
1710They corresponds to outputs that are required for AR5 simulations (CMIP5)
1711(see also Section \ref{DIA_steric} for one of them).
1712Activating those outputs requires to define the \key{diaar5} CPP key.
1713
1714
1715% -----------------------------------------------------------
1716%       25 hour mean and hourly Surface, Mid and Bed
1717% -----------------------------------------------------------
1718\subsection{25 hour mean output for tidal models }
1719
1720%------------------------------------------nam_dia25h-------------------------------------
1721\fortranfile{namelists/nam_dia25h}
1722%-----------------------------------------------------------------------------------------
1723
1724A module is available to compute a crudely detided M2 signal by obtaining a 25 hour mean.
1725The 25 hour mean is available for daily runs by summing up the 25 hourly instantananeous hourly values from
1726midnight at the start of the day to midight at the day end.
1727This diagnostic is actived with the logical  $ln\_dia25h$
1728
1729
1730% -----------------------------------------------------------
1731%     Top Middle and Bed hourly output
1732% -----------------------------------------------------------
1733\subsection{Top Middle and Bed hourly output }
1734
1735%------------------------------------------nam_diatmb-----------------------------------------------------
1736\fortranfile{namelists/nam_diatmb}
1737%----------------------------------------------------------------------------------------------------------
1738
1739A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables.
1740This can be a useful diagnostic when hourly or sub-hourly output is required in high resolution tidal outputs.
1741The tidal signal is retained but the overall data usage is cut to just three vertical levels. Also the bottom level
1742is calculated for each cell.
1743This diagnostic is actived with the logical  $ln\_diatmb$
1744
1745
1746
1747% -----------------------------------------------------------
1748%     Courant numbers
1749% -----------------------------------------------------------
1750\subsection{Courant numbers}
1751Courant numbers provide a theoretical indication of the model's numerical stability. The advective Courant numbers can be calculated according to
1752\begin{equation}
1753\label{eq:CFL}
1754C_u = |u|\frac{\rdt}{e_{1u}}, \quad C_v = |v|\frac{\rdt}{e_{2v}}, \quad C_w = |w|\frac{\rdt}{e_{3w}}
1755\end{equation}
1756in the zonal, meridional and vertical directions respectively. The vertical component is included although it is not strictly valid as the vertical velocity is calculated from the continuity equation rather than as a prognostic variable. Physically this represents the rate at which information is propogated across a grid cell. Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step.
1757
1758The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in the \ngn{namctl} 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 where the maximum value occurs. 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.
1759
1760
1761% ================================================================
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774\end{document}
Note: See TracBrowser for help on using the repository browser.