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

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.

chap_DIA.tex in NEMO/branches/2018/dev_r10164_HPC09_ESIWACE_PREP_MERGE/doc/latex/NEMO/subfiles – NEMO

Context Navigation

source: NEMO/branches/2018/dev_r10164_HPC09_ESIWACE_PREP_MERGE/doc/latex/NEMO/subfiles/chap_DIA.tex @ 10419

Last change on this file since 10419 was 10419, checked in by smasson, 5 years ago
dev_r10164_HPC09_ESIWACE_PREP_MERGE: merge with trunk@10418, see #2133
Property svn:keywords set to `Id`
File size: 98.3 KB

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

Note: See TracBrowser for help on using the repository browser.

Download in other formats: