# source:NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex@10414

Last change on this file since 10414 was 10414, checked in by nicolasmartin, 2 years ago
• Comment \label commands on maths environments for unreferenced equations and adapt the unnumbered math container accordingly (mainly switch to shortanded LateX syntax with $...$)
• Add a code trick to build subfile with its own bibliography
• Fix right path for main LaTeX document in first line of subfiles (\documentclass[...]{subfiles})
• Rename abstract_foreword.tex to foreword.tex
• Fix some non-ASCII codes inserted here or there in LaTeX (0-9]*) • Made a first iteration on the indentation and alignement within math, figure and table environments to improve source code readability • 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 20The model outputs are of three types: the restart file, the output listing, and the diagnostic output file(s). 21The restart file is used internally by the code when the user wants to start the model with 22initial conditions defined by a previous simulation. 23It 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 25the same run performed in one step. 26It should be noted that this requires that the restart file contains two consecutive time steps for 27all the prognostic variables, and that it is saved in the same binary format as the one used by the computer that 28is to read it (in particular, 32 bits binary IEEE format must not be used for this file). 29 30The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs. 31The output listing is stored in the ocean.output file. 32The information is printed from within the code on the logical unit numout. 33To locate these prints, use the UNIX command "\textit{grep -i numout}" in the source code directory. 34 35By default, diagnostic output files are written in NetCDF format. 36Since version 3.2, when defining \key{iomput}, an I/O server has been added which 37provides more flexibility in the choice of the fields to be written as well as how 38the writing work is distributed over the processors in massively parallel computing. 39A complete description of the use of this I/O server is presented in the next section. 40 41By default, \key{iomput} is not defined, 42NEMO produces NetCDF with the old IOIPSL library which has been kept for compatibility and its easy installation. 43However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2, 44many diagnostic options have been added presuming the use of \key{iomput}. 45The usefulness of the default IOIPSL-based option is expected to reduce with each new release. 46If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and 47contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of 48nn\_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 58Since version 3.2, iomput is the NEMO output interface of choice. 59It has been designed to be simple to use, flexible and efficient. 60The 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 71The first functionality allows the user to specify, without code changes or recompilation, 72aspects 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 90In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or 3D) 91in a very easy way. 92All details of iomput functionalities are listed in the following subsections. 93Examples 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 96The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). 97Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) 98to collect and write the outputs. 99With an appropriate choice of N by the user, the bottleneck associated with the writing of 100the output files can be greatly reduced. 101 102In version 3.6, the iom\_put interface depends on 103an 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). 105This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to 106create a single output file and therefore to bypass the rebuilding phase. 107Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to 108an HDF5 library that has been correctly compiled (i.e. with the configure option --enable-parallel). 109Note that the files created by iomput through XIOS are incompatible with NetCDF3. 110All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 111 112Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, 113where N is typically much less than the number of NEMO processors, will reduce the number of output files created. 114This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. 115Note that for smaller configurations, the rebuilding phase can be avoided, 116even 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 122Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, 123the io\_server developed by Yann Meurdesoif from IPSL. 124The behaviour of the I/O subsystem is controlled by settings in the external XML files listed above. 125Key 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 129The {\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 <}]. 132The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications. 133The type of each file can be either ''multiple\_file'' or ''one\_file''. 134 135In \textit{attached mode} and if the type of file is ''multiple\_file'', 136then each NEMO process will also act as an IO server and produce its own set of output files. 137Superficially, this emulates the standard behaviour in previous versions. 138However, the subdomain written out by each process does not correspond to 139the \forcode{jpi x jpj x jpk} domain actually computed by the process (although it may if \forcode{jpni=1}). 140Instead each process will have collected and written out a number of complete longitudinal strips. 141If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and 142write (in parallel) to a single output file. 143 144In \textit{detached mode} and if the type of file is ''multiple\_file'', 145then each stand-alone XIOS process will collect data for a range of complete longitudinal strips and 146write to its own set of output files. 147If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and 148write (in parallel) to a single output file. 149Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. 150The 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 154The number of cores used by the XIOS is specified when launching the model. 155The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of 156cores dedicated to NEMO. 157Some manufacturers suggest using O(\sqrt{N}) dedicated IO processors for N processors but 158this is a general recommendation and not specific to NEMO. 159It is difficult to provide precise recommendations because the optimal choice will depend on 160the particular hardware properties of the target system 161(parallel filesystem performance, available memory, memory bandwidth etc.) 162and the volume and frequency of data to be created. 163Here 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 168As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. 169See 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 215As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. 216See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. 217NEMO will need to link to the compiled XIOS library. 218The \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 223It is very easy to add your own outputs with iomput. 224Many standard fields and diagnostics are already prepared (i.e., steps 1 to 3 below have been done) and 225simply need to be activated by including the required output in a file definition in iodef.xml (step 4). 226To 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 248Note your definition must be added to the field\_group whose reference grid is consistent with the size of 249the array passed to iomput. 250The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, 251reference 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. 253e.g.: 254 255\begin{xmllines} 256<grid id="grid_T_3D" domain_ref="grid_T" axis_ref="deptht"/> 257\end{xmllines} 258 259Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step, 260add 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 281XML tags begin with the less-than character ("<") and end with the greater-than character (">"). 282You use tags to mark the start and end of elements, which are the logical units of information in an XML document. 283In addition to marking the beginning of an element, XML start tags also provide a place to specify attributes. 284An 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>}. 286See \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 290The XML file used in XIOS is structured by 7 families of tags: 291context, axis, domain, grid, field, file and variable. 292Each 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 314Each element may have several attributes. 315Some attributes are mandatory, other are optional but have a default value and other are completely optional. 316Id is a special attribute used to identify an element or a group of elements. 317It must be unique for a kind of element. 318It is optional, but no reference to the corresponding element can be done if it is not defined. 319 320The XML file is split into context tags that are used to isolate IO definition from 321different codes or different parts of a code. 322No interference is possible between 2 different contexts. 323Each context has its own calendar and an associated timestep. 324In \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 399The XML file can be split in different parts to improve its readability and facilitate its use. 400The 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 405are 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 413XML extensively uses the concept of inheritance. 414XML has a tree based structure with a parent-child oriented relation: all children inherit attributes from parent, 415but an attribute defined in a child replace the inherited attribute value. 416Note that the special attribute ''id'' is never inherited. 417\\ 418\\ 419example 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 428The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average'' of 429the attribute ''operation'' from its parent. 430Note that a child can overwrite the attribute definition inherited from its parents. 431In the example above, the field ''sss'' will for example output instantaneous values instead of average values. 432\\ 433\\ 434example 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 449Inherit (and overwrite, if needed) the attributes of a tag you are refering to. 450 451\subsubsection{Use of groups} 452 453Groups can be used for 2 purposes. 454Firstly, the group can be used to define common attributes to be shared by the elements of 455the group through inheritance. 456In the following example, we define a group of field that will share a common grid ''grid\_T\_2D''. 457Note 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 468Secondly, the group can be used to replace a list of elements. 469Several examples of groups of fields are proposed at the end of the file \path{CONFIG/SHARED/field_def.xml}. 470For 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 480that 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 491The file \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml} provides several examples of the use of 492the new functionalities offered by the XML interface of XIOS. 493 494\subsubsection{Define horizontal subdomains} 495 496Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of 497the tag family domain. 498It must therefore be done in the domain part of the XML file. 499For example, in \path{CONFIG/SHARED/domain_def.xml}, we provide the following example of a definition of 500a 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 507The use of this subdomain is done through the redefinition of the attribute domain\_ref of the tag family field. 508For 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 516Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 517The Equatorial section, the TAO, RAMA and PIRATA moorings are already registered in the code and 518can therefore be outputted without taking care of their (i,j) position in the grid. 519These predefined domains can be activated by the use of specific domain\_ref: 520''EqT'', ''EqU'' or ''EqW'' for the equatorial sections and 521the 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 529Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if 530you use the ''multiple\_file'' type for your output files, 531you 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}). 533We are therefore advising to use the ''one\_file'' type in this case. 534 535\subsubsection{Define vertical zooms} 536 537Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis. 538It must therefore be done in the axis part of the XML file. 539For 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 547The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of the tag family field. 548For 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 558The output file names are defined by the attributs ''name'' and ''name\_suffix'' of the tag family file. 559For 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 572However it is often very convienent to define the file name with the name of the experiment, 573the 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). 575To do so, we added the following rule: 576if the id of the tag file is ''fileN'' (where N = 1 to 999 on 1 to 3 digits) or 577one of the predefined sections or moorings (see next subsection), 578the 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} 622cn_exp = "ORCA2" 623nn_date0 = 19891231 624ln_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 631The 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}). 633Any definition given in the XML file will be overwritten. 634By 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 638Here 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 701in 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 707in file\_definition: 708 709\begin{xmllines} 710<field field_ref="sst2" > sst2 </field> 711\end{xmllines} 712 713Note that in this case, the following syntaxe \xmlcode{<field field_ref="sst2" />} is not working as 714sst2 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 726Note that, then the code is crashing, writting real4 variables forces a numerical convection from 727real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. 728Forcing 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="degC*m" 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 765The freq\_op="5d" attribute is used to define the operation frequency of the @'' function: here 5 day. 766The temporal operation done by the @'' is the one defined in the field definition: 767here we use the default, average. 768So, in the above case, @toce\_e3t will do the 5-day mean of toce*e3t. 769Operation="instant" refers to the temporal operation to be performed on the field''@toce\_e3t / @e3t'': 770here the temporal average is alreday done by the @'' function so we just use instant to do the ratio of 771the 2 mean values. 772field\_ref="toce" means that attributes not explicitely defined, are inherited from toce field. 773Note 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 797The freq\_op="1m" attribute is used to define the operation frequency of the @'' function: here 1 month. 798The temporal operation done by the @'' is the one defined in the field definition: 799here we use the default, average. 800So, in the above case, @ssh2 will do the monthly mean of ssh*ssh. 801Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'': 802here the temporal average is alreday done by the @'' function so we just use instant. 803field\_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field. 804Note 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 830The freq\_op="1d" attribute is used to define the operation frequency of the @'' function: here 1 day. 831The temporal operation done by the @'' is the one defined in the field definition: 832here maximum for sstmax and minimum for sstmin. 833So, in the above case, @sstmax will do the daily max and @sstmin the daily min. 834Operation="average" refers to the temporal operation to be performed on the field @sstmax - @sstmin'': 835here monthly mean (of daily max - daily min of the sst). 836field\_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 1279Output 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 1281the CF metadata standard. 1282Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of 1283section \autoref{subsec:IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard. 1284 1285Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by 1286the namelist parameter \np{ln\_cfmeta} in the \ngn{namrun} namelist. 1287This 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 1296Since version 3.3, support for NetCDF4 chunking and (loss-less) compression has been included. 1297These options build on the standard NetCDF output and allow the user control over the size of the chunks via 1298namelist settings. 1299Chunking and compression can lead to significant reductions in file sizes for a small runtime overhead. 1300For a fuller discussion on chunking and other performance issues the reader is referred to 1301the NetCDF4 documentation found \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}. 1302 1303The 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). 1305Datasets created with chunking and compression are not backwards compatible with NetCDF3 "classic" format but 1306most analysis codes can be relinked simply with the new libraries and will then read both NetCDF3 and NetCDF4 files. 1307NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by 1308setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} namelist: 1309 1310%------------------------------------------namnc4---------------------------------------------------- 1311 1312\nlst{namnc4} 1313%------------------------------------------------------------------------------------------------------------- 1314 1315If \key{netcdf4} has not been defined, these namelist parameters are not read. 1316In this case, \np{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined. 1317These functions will not be used but need to be included so that compilation is possible with NetCDF3 libraries. 1318 1319When using NetCDF4 libraries, \key{netcdf4} should be defined even if the intention is to 1320create only NetCDF3-compatible files. 1321This is necessary to avoid duplication between the dummy routines and the actual routines present in the library. 1322Most compilers will fail at compile time when faced with such duplication. 1323Thus when linking with NetCDF4 libraries the user must define \key{netcdf4} and 1324control the type of NetCDF file produced via the namelist parameter. 1325 1326Chunking and compression is applied only to 4D fields and 1327there is no advantage in chunking across more than one time dimension since 1328previously written chunks would have to be read back and decompressed before being added to. 1329Therefore, user control over chunk sizes is provided only for the three space dimensions. 1330The user sets an approximate number of chunks along each spatial axis. 1331The actual size of the chunks will depend on global domain size for mono-processors or, more likely, 1332the local processor domain size for distributed processing. 1333The derived values are subject to practical minimum values (to avoid wastefully small chunk sizes) and 1334cannot be greater than the domain size in any dimension. 1335The algorithm used is: 1336 1337\begin{forlines} 1338ichunksz(1) = MIN(idomain_size, MAX((idomain_size-1) / nn_nchunks_i + 1 ,16 )) 1339ichunksz(2) = MIN(jdomain_size, MAX((jdomain_size-1) / nn_nchunks_j + 1 ,16 )) 1340ichunksz(3) = MIN(kdomain_size, MAX((kdomain_size-1) / nn_nchunks_k + 1 , 1 )) 1341ichunksz(4) = 1 1342\end{forlines} 1343 1344\noindent As an example, setting: 1345 1346\begin{forlines} 1347nn_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 1351the mono-processor case (i.e. global domain of {\small\tt 182x149x31}). 1352An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in 1353table \autoref{tab:NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with 1354a 4x2 mpi partitioning. 1355Note the variation in the compression ratio achieved which reflects chiefly the dry to wet volume ratio of 1356each 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 1399When \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}. 1402Typically this namelist serves the mean files whilst the \ngn{ namnc4} in the main namelist file continues to 1403serve the restart files. 1404This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of 1405the individual files produced by the io\_server processes may be different to those produced by 1406the 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 1419Each 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). 1422This capability is controlled by options offered in \ngn{namtrd} namelist. 1423Note that the output are done with xIOS, and therefore the \key{IOM} is required. 1424 1425What 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 1448Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via 1449the \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. 1452In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are not working, 1453and 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 1465The on-line computation of floats advected either by the three dimensional velocity field or constraint to 1466remain at a given depth (w = 0 in the computation) have been introduced in the system during the CLIPPER project. 1467Options are defined by \ngn{namflo} namelis variables. 1468The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option), 1469or on a 4^th Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}). 1470Note that the \cite{Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which 1471are consistent with the numeric of the code, so that the trajectories never intercept the bathymetry. 1472 1473\subsubsection{Input data: initial coordinates} 1474 1475Initial coordinates can be given with Ariane Tools convention 1476(IJK coordinates, (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude. 1477 1478In case of Ariane convention, input filename is \np{init\_float\_ariane}. 1479Its 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 1501In the other case (longitude and latitude), input filename is init\_float. 1502Its 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. 1527When 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 1533creation of the float restart file. 1534 1535Output data can be written in ascii files (\np{ln\_flo\_ascii}\forcode{ = .true.}). 1536In that case, output filename is trajec\_float. 1537 1538Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii}\forcode{ = .false.}). 1539There are 2 possibilities: 1540 1541- if (\key{iomput}) is used, outputs are selected in iodef.xml. 1542Here 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 1574A module is available to compute the amplitude and phase of tidal waves. 1575This on-line Harmonic analysis is actived with \key{diaharm}. 1576 1577Some 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
1598With $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. \\
1600We 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
1606with $A_{j}=\sqrt{C^{2}_{j}+S^{2}_{j}}$ and $\phi_{j}=arctan(S_{j}/C_{j})$.
1607
1608We obtain in output $C_{j}$ and $S_{j}$ for each tidal wave.
1609
1610% -------------------------------------------------------------------------------------------------------------
1611%       Sections transports
1612% -------------------------------------------------------------------------------------------------------------
1614\label{sec:DIA_diag_dct}
1615
1616%------------------------------------------namdct----------------------------------------------------
1617
1618\nlst{namdct}
1619%-------------------------------------------------------------------------------------------------------------
1620
1621A module is available to compute the transport of volume, heat and salt through sections.
1622This diagnostic is actived with \key{diadct}.
1623
1624Each section is defined by the coordinates of its 2 extremities.
1625The pathways between them are contructed using tools which can be found in \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT}
1626and are written in a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by
1627NEMO to compute on-line transports.
1628
1629The 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
1637Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over which
1638they 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
1646the 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
1649Another file is available for the GYRE configuration (\texttt{ {list\_sections.ascii\_GYRE}}).
1650
1651Each section is defined by: \\
1652\noindent {\scriptsize \texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}} \\
1653with:
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
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
1715
1716The 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
1726For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for each class and
1727the last line corresponds to the total transport summed over all classes.
1728For sections with no classes, class number \texttt{1} corresponds to \texttt{total class} and
1729this 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
1736direction: \\
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
1760Changes in steric sea level are caused when changes in the density of the water column imply an expansion or
1761contraction of the column.
1762It is essentially produced through surface heating/cooling and to a lesser extent through non-linear effects of
1763the equation of state (cabbeling, thermobaricity...).
1764Non-Boussinesq models contain all ocean effects within the ocean acting on the sea level.
1765In particular, they include the steric effect.
1766In contrast, Boussinesq models, such as \NEMO, conserve volume, rather than mass,
1767and so do not properly represent expansion or contraction.
1768The steric effect is therefore not explicitely represented.
1769This 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,
1771as steric changes are an important contribution to local changes in sea level on seasonal and climatic time scales.
1772This is especially true for investigation into sea level rise due to global warming.
1773
1774Fortunately, the steric contribution to the sea level consists of a spatially uniform component that
1775can be diagnosed by considering the mass budget of the world ocean \citep{Greatbatch_JGR94}.
1776In order to better understand how global mean sea level evolves and thus how the steric sea level can be diagnosed,
1777we compare, in the following, the non-Boussinesq and Boussinesq cases.
1778
1779Let 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
1788A 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
1798Temporal 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
1806where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass exchanges with the other media of
1807the Earth system (atmosphere, sea-ice, land).
1808Its 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
1815where $\overline{\textit{emp}} = \int_S \textit{emp}\,ds$ is the net mass flux through the ocean surface.
1816Bringing \autoref{eq:Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to
1817the 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
1825The first term in equation \autoref{eq:ssh_nBq} alters sea level by adding or subtracting mass from the ocean.
1826The second term arises from temporal changes in the global mean density; $i.e.$ from steric effects.
1827
1828In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ appears multiplied by
1829the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations).
1830In 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
1837and 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
1844Only 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}$.
1846The total volume (or equivalently the global mean sea level) is altered only by net volume fluxes across
1847the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid.
1848
1849Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by
1850considering the mass budget of the ocean.
1851The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface mass flux
1852must be compensated by a spatially uniform change in the mean sea level due to expansion/contraction of the ocean
1853\citep{Greatbatch_JGR94}.
1854In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$,
1855the 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
1863Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through the ocean surface
1864is converted into a mean change in sea level.
1865Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$,
1866where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos})
1867in \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
1874The above formulation of the steric height of a Boussinesq ocean requires four remarks.
1875First, 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.
1877We do not recommend that.
1878Indeed, in this case $\rho_o$ depends on the initial state of the ocean.
1879Since $\rho_o$ has a direct effect on the dynamics of the ocean
1880(it appears in the pressure gradient term of the momentum equation)
1881it is definitively not a good idea when inter-comparing experiments.
1882We better recommend to fixe once for all $\rho_o$ to $1035\;Kg\,m^{-3}$.
1883This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since,
1884with the exception of only a small percentage of the ocean, density in the World Ocean varies by no more than
18852$\%$ from this value (\cite{Gill1982}, page 47).
1886
1887Second, we have assumed here that the total ocean surface, $\mathcal{A}$,
1888does 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
1891Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of free surface which is considered.
1892In 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
1899whereas in the linear free surface,
1900the volume above the \textit{z=0} surface must be explicitly taken into account to
1901better 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
1909The fourth and last remark concerns the effective sea level and the presence of sea-ice.
1910In the real ocean, sea ice (and snow above it)  depresses the liquid seawater through its mass loading.
1911This depression is a result of the mass of sea ice/snow system acting on the liquid ocean.
1912There is, however, no dynamical effect associated with these depressions in the liquid ocean sea level,
1913so that there are no associated ocean currents.
1914Hence, 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}.
1916However, in the current version of \NEMO the sea-ice is levitating above the ocean without mass exchanges between
1917ice and ocean.
1918Therefore the model effective sea level is always given by $\eta + \eta_s$, whether or not there is sea ice present.
1919
1920In AR5 outputs, the thermosteric sea level is demanded.
1921It is steric sea level due to changes in ocean density arising just from changes in temperature.
1922It 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
1929where $S_o$ and $p_o$ are the initial salinity and pressure, respectively.
1930
1931Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs the \key{diaar5} defined to
1932be called.
1933
1934% -------------------------------------------------------------------------------------------------------------
1935%       Other Diagnostics
1936% -------------------------------------------------------------------------------------------------------------
1937\section{Other diagnostics (\protect\key{diahth}, \protect\key{diaar5})}
1938\label{sec:DIA_diag_others}
1939
1940Aside from the standard model variables, other diagnostics can be computed on-line.
1942
1943\subsection{Depth of various quantities (\protect\mdl{diahth})}
1944
1945Among 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
1966The poleward heat and salt transports, their advective and diffusive component,
1967and 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).
1969When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic, Indian,
1970Pacific and Indo-Pacific Oceans (defined north of 30\deg S) as well as for the World Ocean.
1971The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains three 2D mask arrays,
1973
1974%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1975\begin{figure}[!t]
1976  \begin{center}
1978    \caption{
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
1995A series of diagnostics has been added in the \mdl{diaar5}.
1996They corresponds to outputs that are required for AR5 simulations (CMIP5)
1998Activating 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
2010A module is available to compute a crudely detided M2 signal by obtaining a 25 hour mean.
2011The 25 hour mean is available for daily runs by summing up the 25 hourly instantananeous hourly values from
2012midnight at the start of the day to midight at the day end.
2013This 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
2025A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables.
2026This can be a useful diagnostic when hourly or sub-hourly output is required in high resolution tidal outputs.
2027The tidal signal is retained but the overall data usage is cut to just three vertical levels.
2028Also the bottom level is calculated for each cell.
2029This diagnostic is actived with the logical $ln\_diatmb$.
2030
2031% -----------------------------------------------------------
2032%     Courant numbers
2033% -----------------------------------------------------------
2034\subsection{Courant numbers}
2035
2036Courant numbers provide a theoretical indication of the model's numerical stability.
2037The 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
2044in the zonal, meridional and vertical directions respectively.
2045The vertical component is included although it is not strictly valid as the vertical velocity is calculated from
2046the continuity equation rather than as a prognostic variable.
2047Physically this represents the rate at which information is propogated across a grid cell.
2048Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step.
2049
2050The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in the \ngn{namctl} namelist.
2051The diagnostics will be written out to an ascii file named cfl\_diagnostics.ascii.
2052In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with the coordinates of
2053where the maximum value occurs.
2054At 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
2055with the coordinates of each.
2056The 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.