source: branches/2014/dev_r4650_UKMO14.12_STAND_ALONE_OBSOPER/DOC/TexFiles/Chapters/Chap_DIA.tex @ 5600

Last change on this file since 5600 was 5600, checked in by andrewryan, 5 years ago

merged in latest version of trunk alongside changes to SAO_SRC to be compatible with latest OBS

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