source: branches/2013/dev_r3853_CNRS9_ConfSetting/DOC/TexFiles/Chapters/Chap_DIA.tex @ 3989

Last change on this file since 3989 was 3989, checked in by clevy, 8 years ago

Configuration setting/Step3 and doc, see ticket:#1074

File size: 54.2 KB
Line 
1% ================================================================
2% Chapter � I/O & Diagnostics
3% ================================================================
4\chapter{Ouput and Diagnostics (IOM, DIA, TRD, FLO)}
5\label{DIA}
6\minitoc
7
8\newpage
9$\ $\newline    % force a new ligne
10
11% ================================================================
12%       Old Model Output
13% ================================================================
14\section{Old Model Output (default or \key{dimgout})}
15\label{DIA_io_old}
16
17The model outputs are of three types: the restart file, the output listing,
18and the output file(s). The restart file is used internally by the code when
19the user wants to start the model with initial conditions defined by a
20previous simulation. It contains all the information that is necessary in
21order for there to be no changes in the model results (even at the computer
22precision) between a run performed with several restarts and the same run
23performed in one step. It should be noted that this requires that the restart file
24contain two consecutive time steps for all the prognostic variables, and
25that it is saved in the same binary format as the one used by the computer
26that is to read it (in particular, 32 bits binary IEEE format must not be used for
27this file). The output listing and file(s) are predefined but should be checked
28and eventually adapted to the user's needs. The output listing is stored in
29the $ocean.output$ file. The information is printed from within the code on the
30logical unit $numout$. To locate these prints, use the UNIX command
31"\textit{grep -i numout}" in the source code directory.
32
33In the standard configuration, the user will find the model results in
34NetCDF files containing mean values (or instantaneous values if
35\key{diainstant} is defined) for every time-step where output is demanded.
36These outputs are defined in the \mdl{diawri} module.
37When defining \key{dimgout}, the output are written in DIMG format,
38an IEEE output format.
39
40Since version 3.2, an I/O server has been added which provides more
41flexibility in the choice of the fields to be output as well as how the
42writing work is distributed over the processors in massively parallel
43computing. It is presented in next section.
44
45
46%\gmcomment{                    % start of gmcomment
47
48% ================================================================
49% Diagnostics
50% ================================================================
51\section{Standard model Output (IOM)}
52\label{DIA_iom}
53
54
55Since version 3.2, iom\_put is the NEMO output interface. It was designed to be simple to use,
56flexible and efficient. Two main functionalities are covered by iom\_put:
57(1) the control of the output files through an external xml file defined by the user ;
58(2) the distribution (or not) of all task related to output files on dedicated processors.
59The first functionality allows the user to specify, without touching anything into the code,
60the way he want to output data: \\
61- choice of output frequencies that can be different for each file (including real months and years) \\
62- choice of file contents: decide which data will be written in which file (the same data can be
63outputted in different files)  \\
64- possibility to extract a subdomain (for example all TAO-PIRATA-RAMA moorings are already defined)  \\
65- choice of the temporal operation to perform: mean, instantaneous, min, max  \\
66- extremely large choice of data available   \\
67- redefine variables name and long\_name  \\
68In addition, iom\_put allows the user to output any variable (scalar, 2D or 3D) in the code
69in a very easy way. All details of iom\_put functionalities are listed in the following subsections.
70An example of the iodef.xml file that control the outputs can be found here:
71NEMOGCM/CONFIG/ORCA2\_LIM/EXP00/iodef.xml
72
73The second functionality targets outputs performances when running on a very large number of processes.
74The idea is to dedicate N specific processes to write the outputs, where N is defined by the user.
75In the current version, this functionality is technically working however, its performance are usually poor
76(for known reasons). Users can therefore test this functionality but they must be aware that expected
77performance improvement will not be achieved before the release 3.4.
78An example of xmlio\_server.def NEMOGCM/CONFIG/ORCA2\_LIM/EXP00/xmlio\_server.def
79 
80
81\subsection{Basic knowledge}
82
83
84\subsubsection{ XML basic rules}
85
86XML tags begin with the less-than character ("$<$") and end with the greater-than character (''$>$'').
87You use tags to mark the start and end of elements, which are the logical units of information
88in an XML document. In addition to marking the beginning of an element, XML start tags also
89provide a place to specify attributes. An attribute specifies a single property for an element,
90using a name/value pair, for example: $<$a b="x" c="y" b="z"$>$ ... $<$/a$>$.
91See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details.
92
93\subsubsection{Structure of the xml file used in NEMO}
94
95The xml file is split into 3 parts:
96\begin{description}
97\item[field definition]: define all variables that can be output \\
98all lines in between the following two tags\\
99\verb?   <field\_definition ...> ?  \\
100\verb?   </field\_definition ...> ?
101\item[file definition]: define the netcdf files to be created and the variables they will contain \\
102all lines in between the following two tags \\
103\verb?   <field\_definition> ?  \\
104\verb?   </field\_definition> ?
105\item[axis and grid definitions]: define the horizontal and vertical grids \\
106all lines in between the following two set of two tags\\
107\verb?   <axis\_definition ...> ?  \\
108\verb?   </axis\_definition ...> ?
109and \\
110\verb?   <grid\_definition ...> ?  \\
111\verb?   </grid\_definition ...> ?
112\end{description}
113
114\subsubsection{Inheritance and group }
115
116 Xml extensively uses the concept of inheritance. \\
117\\
118example 1: \\
119\vspace{-30pt}
120\begin{alltt}  {{\scriptsize   
121\begin{verbatim}
122   <field_definition operation="ave(X)" >
123      <field id="sst"                    />   <!-- averaged      sst -->
124      <field id="sss" operation="inst(X)"/>   <!-- instantaneous sss -->
125   </field_definition>
126\end{verbatim}
127}}\end{alltt} 
128
129The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''ave(X)''
130of the attribute ''operation'' from its parent ''field definition''. Note that a child can overwrite
131the attribute definition inherited from its parents. In the example above, the field ''sss'' will
132therefore output instantaneous values instead of average values.
133
134example 2: Use (or overwrite) attributes value of a field when listing the variables included in a file
135\vspace{-20pt}
136\begin{alltt}  {{\scriptsize
137\begin{verbatim}
138   <field_definition>
139      <field id="sst" description="sea surface temperature" />   
140      <field id="sss" description="sea surface salinity"    /> 
141   </field_definition>     
142
143   <file_definition>
144      <file id="file_1" />   
145            <field ref="sst"                              />  <!-- default def -->
146            <field ref="sss" description="my description" />  <!-- overwrite   -->
147      </file>   
148   </file_definition>
149\end{verbatim}
150}}\end{alltt} 
151
152With the help of the inheritance, the concept of group allow to define a set of attributes
153for several fields or files.
154
155example 3, group of fields: define a group ''T\_grid\_variables'' identified with the name
156''grid\_T''. By default variables of this group have no vertical axis but, following inheritance
157rules, ''axis\_ref'' can be redefined for the field ''toce'' that is a 3D variable.
158\vspace{-30pt}
159\begin{alltt}  {{\scriptsize
160\begin{verbatim}
161   <field_definition>
162      <group id="grid_T" axis_ref="none" grid_ref="T_grid_variables">
163            <field id="sst"/> 
164            <field id="sss"/> 
165            <field id="toce" axis_ref="deptht"/>  <!-- overwrite axis def -->
166      </group>
167   </field_definition>
168\end{verbatim}
169}}\end{alltt} 
170
171example 4, group of files: define a group of file with the attribute output\_freq equal to 432000 (5 days)
172\vspace{-30pt}
173\begin{alltt}  {{\scriptsize
174\begin{verbatim}
175   <file_definition>
176      <group id="5d" output_freq="432000">    <!-- 5d files -->
177         <file id="5d_grid_T" name="auto">   <!-- T grid file -->
178         ...
179         </file>
180         <file id="5d_grid_U" name="auto">   <!-- U grid file -->
181         ...
182         </file>
183      </group>
184   </file_definition>
185\end{verbatim}
186}}\end{alltt} 
187
188\subsubsection{Control of the xml attributes from NEMO}
189
190The values of some attributes are automatically defined by NEMO (and any definition
191given in the xml file is overwritten). By convention, these attributes are defined to ''auto''
192(for string) or ''0000'' (for integer) in the xml file (but this is not necessary).
193
194Here is the list of these attributes: \\
195\\
196\begin{tabular}{|l|c|c|c|}
197   \hline
198 \multicolumn{2}{|c|}{tag ids affected by automatic           }  & name      & attribute value \\
199  \multicolumn{2}{|c|}{definition of some of their attributes }  & attribute  &        \\
200   \hline
201   \hline
202    \multicolumn{2}{|c|}{field\_definition} & freq\_op & \np{rn\_rdt} \\
203   \hline
204    \multicolumn{2}{|c|}{SBC}                  & freq\_op & \np{rn\_rdt} $\times$ \np{nn\_fsbc} \\
205   \hline
206    1h, 2h, 3h, 4h, 6h, 12h & \_grid\_T, \_grid\_U,  &  name & filename defined by   \\
207    1d, 3d, 5d                     & \_grid\_V, \_grid\_W, &            & a call to rou{dia\_nam}  \\
208    1m, 2m, 3m, 4m, 6m    & \_icemod, \_ptrc\_T,  &            & following NEMO \\
209    1y, 2y, 5y, 10y               &  \_diad\_T, \_scalar   &            & nomenclature \\
210   \hline
211    \multicolumn{2}{|c|}{EqT, EqU, EqW} & jbegin, ni,      & according to the grid    \\
212    \multicolumn{2}{|c|}{                         } & name\_suffix &                                      \\
213   \hline
214    \multicolumn{2}{|c|}{TAO, RAMA and PIRATA moorings} & ibegin, jbegin,      & according to the grid    \\
215    \multicolumn{2}{|c|}{                                                       } & name\_suffix &                                      \\
216   \hline
217\end{tabular}
218
219
220\subsection{ Detailed functionalities }
221
222\subsubsection{Tag list}
223
224\begin{description}
225
226\item[context]: define the model using the xml file. Id is the only attribute accepted.
227Its value must be ''nemo'' or ''n\_nemo'' for the nth AGRIF zoom. Child of simulation tag.
228
229\item[field]: define the field to be output. Accepted attributes are axis\_ref, description, enable,
230freq\_op, grid\_ref, id (if child of field\_definition), level, operation, name, ref (if child of file),
231unit, zoom\_ref. Child of field\_definition, file or group of fields tag.
232
233\item[field\_definition]: definition of the part of the xml file corresponding to the field definition.
234Accept the same attributes as field tag. Child of context tag.
235
236\item[group]: define a group of file or field. Accept the same attributes as file or field.
237
238\item[file]: define the output file's characteristics. Accepted attributes are description, enable,
239output\_freq, output\_level, id, name, name\_suffix. Child of file\_definition or group of files tag.
240
241\item[file\_definition]: definition of the part of the xml file corresponding to the file definition.
242Accept the same attributes as file tag. Child of context tag.
243
244\item[axis]: definition of the vertical axis. Accepted attributes are description, id, positive, size, unit.
245Child of axis\_definition tag.
246
247\item[axis\_definition]: definition of the part of the xml file corresponding to the vertical axis definition.
248Accept the same attributes as axis tag. Child of context tag
249
250\item[grid]: definition of the horizontal grid. Accepted attributes are description and id.
251Child of axis\_definition tag.
252
253\item[grid\_definition]: definition of the part of the xml file corresponding to the horizontal grid definition.
254Accept the same attributes as grid tag. Child of context tag
255
256\item[zoom]: definition of a subdomain of an horizontal grid. Accepted attributes are description, id,
257i/jbegin, ni/j. Child of grid tag.
258
259\end{description}
260
261
262\subsubsection{Attributes list}
263
264Applied to a tag or a group of tags.
265
266% table to be added ?
267Another table, perhaps?
268
269%%%%
270
271Attribute
272Applied to?
273Definition
274Comment
275axis\_ref
276field
277String defining the vertical axis of the variable. It refers to the id of the vertical axis defined in the axis tag.
278Use ''non'' if the variable has no vertical axis
279
280%%%%%%
281
282\begin{description}
283
284\item[axis\_ref]: field attribute. String defining the vertical axis of the variable.
285It refers to the id of the vertical axis defined in the axis tag.
286Use ''none'' if the variable has no vertical axis
287
288\item[description]: this attribute can be applied to all tags but it is used only with the field tag.
289In this case, the value of description will be used to define, in the output netcdf file,
290the attributes long\_name and standard\_name of the variable.
291
292\item[enabled]: field and file attribute. Logical to switch on/off the output of a field or a file.
293
294\item[freq\_op]: field attribute (automatically defined, see part 1.4 (''control of the xml attributes'')).
295An integer defining the frequency in seconds at which NEMO is calling iom\_put for this variable.
296It corresponds to the model time step (rn\_rdt in the namelist) except for the variables computed
297at the frequency of the surface boundary condition (rn\_rdt ? nn\_fsbc in the namelist).   
298
299\item[grid\_ref]: field attribute. String defining the horizontal grid of the variable.
300It refers to the id of the grid tag.
301
302\item[ibegin]: zoom attribute. Integer defining the zoom starting point along x direction.
303Automatically defined for TAO/RAMA/PIRATA moorings (see part 1.4). 
304
305\item[id]: exists for all tag. This is a string defining the name to a specific tag that will be used
306later to refer to this tag. Tags of the same category must have different ids.
307
308\item[jbegin]: zoom attribute. Integer defining the zoom starting point along y direction.
309Automatically defined for TAO/RAMA/PIRATA moorings and equatorial section (see part 1.4).
310
311\item[level]: field attribute. Integer from 0 to 10 defining the output priority of a field.
312See output\_level attribute definition
313
314\item[operation]: field attribute. String defining the type of temporal operation to perform on a variable.
315Possible choices are ''ave(X)'' for temporal mean, ''inst(X)'' for instantaneous, ''t\_min(X)'' for temporal min
316and ''t\_max(X)'' for temporal max.
317
318\item[output\_freq]: file attribute. Integer defining the operation frequency in seconds.
319For example 86400 for daily mean.
320
321\item[output\_level]: file attribute. Integer from 0 to 10 defining the output priority of variables in a file:
322all variables listed in the file with a level smaller or equal to output\_level will be output.
323Other variables won't be output even if they are listed in the file. 
324
325\item[positive]: axis attribute (always .FALSE.). Logical defining the vertical axis convention used
326in \NEMO (positive downward). Define the attribute positive of the variable in the netcdf output file.
327
328\item[prec]: field attribute. Integer defining the output precision.
329Not implemented, we always output real4 arrays.
330
331\item[name]: field or file attribute. String defining the name of a variable or a file.
332If the name of a file is undefined, its id is used as a name. 2 files must have different names.
333Files with specific ids will have their name automatically defined (see part 1.4).
334Note that is name will be automatically completed by the cpu number (if needed) and ''.nc''
335
336\item[name\_suffix]: file attribute. String defining a suffix to be inserted after the name
337and before the cpu number and the ''.nc'' termination. Files with specific ids have an
338automatic definition of their suffix (see part 1.4).
339
340\item[ni]: zoom attribute. Integer defining the zoom extent along x direction.
341Automatically defined for equatorial sections (see part 1.4). 
342
343\item[nj]: zoom attribute. Integer defining the zoom extent along x direction.
344
345\item[ref]: field attribute. String referring to the id of the field we want to add in a file.
346
347\item[size]: axis attribute. use unknown...
348
349\item[unit]: field attribute. String defining the unit of a variable and the associated
350attribute in the netcdf output file.
351
352\item[zoom\_ref]: field attribute. String defining the subdomain of data on which
353the file should be written (to ouput data only in a limited area).
354It refers to the id of a zoom defined in the zoom tag.
355\end{description}
356
357
358\subsection{IO\_SERVER}
359
360\subsubsection{Attached or detached mode?}
361
362Iom\_put is based on the io\_server developed by Yann Meurdesoif from IPSL
363(see \href{http://forge.ipsl.jussieu.fr/ioserver/browser}{here} for the source code or
364see its copy in NEMOGCM/EXTERNAL directory).
365This server can be used in ''attached mode'' (as a library) or in ''detached mode''
366(as an external executable on n cpus). In attached mode, each cpu of NEMO will output
367its own subdomain. In detached mode, the io\_server will gather data from NEMO
368and output them split over n files with n the number of cpu dedicated to the io\_server.
369
370\subsubsection{Control the io\_server: the namelist file xmlio\_server.def}
371
372%
373%Again, a small table might be more readable?
374%Name
375%Type
376%Description
377%Comment
378%Using_server
379%Logical
380%Switch to use the server in attached or detached mode
381%(.TRUE. corresponding to detached mode).
382
383The control of the use of the io\_server is done through the namelist file of the io\_server
384called xmlio\_server.def.
385
386\textbf{using\_server}: logical, switch to use the server in attached or detached mode
387(.TRUE. corresponding to detached mode).
388
389\textbf{using\_oasis}: logical, set to .TRUE. if NEMO is used in coupled mode.
390
391\textbf{client\_id} = ''oceanx'' : character, used only in coupled mode.
392Specify the id used in OASIS to refer to NEMO. The same id must be used to refer to NEMO
393in the \$NBMODEL part of OASIS namcouple in the call of prim\_init\_comp\_proto in cpl\_oasis3f90
394
395\textbf{server\_id} = ''ionemo'' : character, used only in coupled mode.
396Specify the id used in OASIS to refer to the IO\_SERVER when used in detached mode.
397Use the same id to refer to the io\_server in the \$NBMODEL part of OASIS namcouple.
398
399\textbf{global\_mpi\_buffer\_size}: integer; define the size in Mb of the MPI buffer used by the io\_server.
400
401\subsubsection{Number of cpu used by the io\_server in detached mode}
402
403The number of cpu used by the io\_server is specified only when launching the model.
404Here is an example of 2 cpus for the io\_server and 6 cpu for opa using mpirun:
405
406\texttt{ -p 2 -e ./ioserver}
407
408\texttt{ -p 6 -e ./opa }
409
410
411\subsection{Practical issues}
412
413\subsubsection{Add your own outputs}
414
415It is very easy to add you own outputs with iom\_put. 4 points must be followed.
416\begin{description}
417\item[1-] in NEMO code, add a \\
418\texttt{      CALL iom\_put( 'identifier', array ) } \\
419where you want to output a 2D or 3D array.
420
421\item[2-] don't forget to add \\
422\texttt{   USE iom            ! I/O manager library }  \\
423in the list of used modules in the upper part of your module.
424
425\item[3-] in the file\_definition part of the xml file, add the definition of your variable using the same identifier you used in the f90 code.
426\vspace{-20pt}
427\begin{alltt}  {{\scriptsize
428\begin{verbatim}
429   <field_definition>
430      ...
431      <field id="identifier" description="blabla" />   
432      ...
433   </field_definition>
434\end{verbatim}
435}}\end{alltt} 
436attributes axis\_ref and grid\_ref must be consistent with the size of the array to pass to iom\_put.
437if your array is computed within the surface module each nn\_fsbc time\_step,
438add the field definition within the group defined with the id ''SBC'': $<$group id=''SBC''...$>$
439
440\item[4-] add your field in one of the output files   \\
441\vspace{-20pt}
442\begin{alltt}  {{\scriptsize
443\begin{verbatim}
444   <file id="file_1" .../>   
445      ...
446      <field ref="identifier" />   
447      ...
448   </file>   
449\end{verbatim}
450}}\end{alltt} 
451
452\end{description}
453
454\subsubsection{Several time axes in the output file}
455
456If your output file contains variables with different operations (see operation definition),
457IOIPSL will create one specific time axis for each operation. Note that inst(X) will have
458a time axis corresponding to the end each output period whereas all other operators
459will have a time axis centred in the middle of the output periods.
460
461\subsubsection{Error/bug messages from IOIPSL}
462
463If you get the following error in the standard output file:
464\vspace{-20pt}
465\begin{alltt}  {{\scriptsize
466\begin{verbatim}
467FATAL ERROR FROM ROUTINE flio_dom_set
468 --> too many domains simultaneously defined
469 --> please unset useless domains
470 --> by calling flio_dom_unset
471\end{verbatim}
472}}\end{alltt} 
473
474You must increase the value of dom\_max\_nb in fliocom.f90 (multiply it by 10 for example).
475
476If you mix, in the same file, variables with different freq\_op (see definition above),
477like for example variables from the surface module with other variables,
478IOIPSL will print in the standard output file warning messages saying there may be a bug.
479\vspace{-20pt}
480\begin{alltt}  {{\scriptsize
481\begin{verbatim}
482WARNING FROM ROUTINE histvar_seq   
483 --> There were 10 errors in the learned sequence of variables 
484 --> for file   4
485 --> This looks like a bug, please report it.
486\end{verbatim}
487}}\end{alltt} 
488
489Don't worry, there is no bug, everything is properly working!
490
491 %    }      %end  \gmcomment
492
493
494% ================================================================
495%       NetCDF4 support
496% ================================================================
497\section{NetCDF4 Support (\key{netcdf4})}
498\label{DIA_iom}
499
500Since version 3.3, support for NetCDF4 chunking and (loss-less) compression has
501been included.  These options build on the standard NetCDF output and allow
502the user control over the size of the chunks via namelist settings. Chunking
503and compression can lead to significant reductions in file sizes for a small
504runtime overhead. For a fuller discussion on chunking and other performance
505issues the reader is referred to the NetCDF4 documentation found
506\href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}.
507
508The new features are only available when the code has been linked with a
509NetCDF4 library (version 4.1 onwards, recommended) which has been built
510with HDF5 support (version 1.8.4 onwards, recommended). Datasets created
511with chunking and compression are not backwards compatible with NetCDF3
512"classic" format but most analysis codes can be relinked simply with the
513new libraries and will then read both NetCDF3 and NetCDF4 files. NEMO
514executables linked with NetCDF4 libraries can be made to produce NetCDF3
515files by setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} 
516namelist:
517
518%------------------------------------------namnc4----------------------------------------------------
519\namdisplay{namnc4}
520%-------------------------------------------------------------------------------------------------------------
521
522If \key{netcdf4} has not been defined, these namelist parameters are not read.
523In this case, \np{ln\_nc4zip} is set false and dummy routines for a few
524NetCDF4-specific functions are defined. These functions will not be used but
525need to be included so that compilation is possible with NetCDF3 libraries.
526
527When using NetCDF4 libraries, \key{netcdf4} should be defined even if the
528intention is to create only NetCDF3-compatible files. This is necessary to
529avoid duplication between the dummy routines and the actual routines present
530in the library. Most compilers will fail at compile time when faced with
531such duplication. Thus when linking with NetCDF4 libraries the user must
532define \key{netcdf4} and control the type of NetCDF file produced via the
533namelist parameter.
534
535Chunking and compression is applied only to 4D fields and there is no
536advantage in chunking across more than one time dimension since previously
537written chunks would have to be read back and decompressed before being
538added to. Therefore, user control over chunk sizes is provided only for the
539three space dimensions. The user sets an approximate number of chunks along
540each spatial axis. The actual size of the chunks will depend on global domain
541size for mono-processors or, more likely, the local processor domain size for
542distributed processing. The derived values are subject to practical minimum
543values (to avoid wastefully small chunk sizes) and cannot be greater than the
544domain size in any dimension. The algorithm used is:
545
546\begin{alltt}  {{\scriptsize 
547\begin{verbatim}
548     ichunksz(1) = MIN( idomain_size,MAX( (idomain_size-1)/nn_nchunks_i + 1 ,16 ) )
549     ichunksz(2) = MIN( jdomain_size,MAX( (jdomain_size-1)/nn_nchunks_j + 1 ,16 ) )
550     ichunksz(3) = MIN( kdomain_size,MAX( (kdomain_size-1)/nn_nchunks_k + 1 , 1 ) )
551     ichunksz(4) = 1
552\end{verbatim}
553}}\end{alltt} 
554
555\noindent As an example, setting:
556\vspace{-20pt}
557\begin{alltt}  {{\scriptsize
558\begin{verbatim}
559     nn_nchunks_i=4, nn_nchunks_j=4 and nn_nchunks_k=31
560\end{verbatim}
561}}\end{alltt} \vspace{-10pt}
562
563\noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\tt 46x38x1}
564respectively in the mono-processor case (i.e. global domain of {\small\tt 182x149x31}).
565An illustration of the potential space savings that NetCDF4 chunking and compression
566provides is given in table \ref{Tab_NC4} which compares the results of two short
567runs of the ORCA2\_LIM reference configuration with a 4x2 mpi partitioning. Note
568the variation in the compression ratio achieved which reflects chiefly the dry to wet
569volume ratio of each processing region.
570
571%------------------------------------------TABLE----------------------------------------------------
572\begin{table}  \begin{tabular}{lrrr}
573Filename & NetCDF3 & NetCDF4 & Reduction\\
574         &filesize & filesize & \% \\
575         &(KB)     & (KB)     & \\
576ORCA2\_restart\_0000.nc & 16420 & 8860 & 47\%\\
577ORCA2\_restart\_0001.nc & 16064 & 11456 & 29\%\\
578ORCA2\_restart\_0002.nc & 16064 & 9744 & 40\%\\
579ORCA2\_restart\_0003.nc & 16420 & 9404 & 43\%\\
580ORCA2\_restart\_0004.nc & 16200 & 5844 & 64\%\\
581ORCA2\_restart\_0005.nc & 15848 & 8172 & 49\%\\
582ORCA2\_restart\_0006.nc & 15848 & 8012 & 50\%\\
583ORCA2\_restart\_0007.nc & 16200 & 5148 & 69\%\\
584ORCA2\_2d\_grid\_T\_0000.nc & 2200 & 1504 & 32\%\\
585ORCA2\_2d\_grid\_T\_0001.nc & 2200 & 1748 & 21\%\\
586ORCA2\_2d\_grid\_T\_0002.nc & 2200 & 1592 & 28\%\\
587ORCA2\_2d\_grid\_T\_0003.nc & 2200 & 1540 & 30\%\\
588ORCA2\_2d\_grid\_T\_0004.nc & 2200 & 1204 & 46\%\\
589ORCA2\_2d\_grid\_T\_0005.nc & 2200 & 1444 & 35\%\\
590ORCA2\_2d\_grid\_T\_0006.nc & 2200 & 1428 & 36\%\\
591ORCA2\_2d\_grid\_T\_0007.nc & 2200 & 1148 & 48\%\\
592             ...            &  ... &  ... & ..  \\
593ORCA2\_2d\_grid\_W\_0000.nc & 4416 & 2240 & 50\%\\
594ORCA2\_2d\_grid\_W\_0001.nc & 4416 & 2924 & 34\%\\
595ORCA2\_2d\_grid\_W\_0002.nc & 4416 & 2512 & 44\%\\
596ORCA2\_2d\_grid\_W\_0003.nc & 4416 & 2368 & 47\%\\
597ORCA2\_2d\_grid\_W\_0004.nc & 4416 & 1432 & 68\%\\
598ORCA2\_2d\_grid\_W\_0005.nc & 4416 & 1972 & 56\%\\
599ORCA2\_2d\_grid\_W\_0006.nc & 4416 & 2028 & 55\%\\
600ORCA2\_2d\_grid\_W\_0007.nc & 4416 & 1368 & 70\%\\
601\end{tabular}
602\caption{   \label{Tab_NC4} 
603Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression}
604\end{table}
605%----------------------------------------------------------------------------------------------------
606
607When \key{iomput} is activated with \key{netcdf4} chunking and
608compression parameters for fields produced via \np{iom\_put} calls are
609set via an equivalent and identically named namelist to \textit{namnc4} 
610in \np{xmlio\_server.def}. Typically this namelist serves the mean files
611whilst the \ngn{ namnc4} in the main namelist file continues to serve the
612restart files. This duplication is unfortunate but appropriate since, if
613using io\_servers, the domain sizes of the individual files produced by the
614io\_server processes may be different to those produced by the invidual
615processing regions and different chunking choices may be desired.
616 
617
618% -------------------------------------------------------------------------------------------------------------
619%       Tracer/Dynamics Trends
620% -------------------------------------------------------------------------------------------------------------
621\section[Tracer/Dynamics Trends (TRD)]
622                  {Tracer/Dynamics Trends  (\key{trdtra}, \key{trddyn},    \\ 
623                                                             \key{trddvor}, \key{trdmld})}
624\label{DIA_trd}
625
626%------------------------------------------namtrd----------------------------------------------------
627\namdisplay{namtrd} 
628%-------------------------------------------------------------------------------------------------------------
629
630When \key{trddyn} and/or \key{trddyn} CPP variables are defined, each
631trend of the dynamics and/or temperature and salinity time evolution equations
632is stored in three-dimensional arrays just after their computation ($i.e.$ at the end
633of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). Options are defined by
634\ngn{namtrd} namelist variables. These trends are then
635used in \mdl{trdmod} (see TRD directory) every \textit{nn\_trd } time-steps.
636
637What is done depends on the CPP keys defined:
638\begin{description}
639\item[\key{trddyn}, \key{trdtra}] : a check of the basin averaged properties of the momentum
640and/or tracer equations is performed ;
641\item[\key{trdvor}] : a vertical summation of the moment tendencies is performed,
642then the curl is computed to obtain the barotropic vorticity tendencies which are output ;
643\item[\key{trdmld}] : output of the tracer tendencies averaged vertically 
644either over the mixed layer (\np{nn\_ctls}=0),
645or       over a fixed number of model levels (\np{nn\_ctls}$>$1 provides the number of level),
646or       over a spatially varying but temporally fixed number of levels (typically the base
647of the winter mixed layer) read in \ifile{ctlsurf\_idx} (\np{nn\_ctls}=1) ;
648\end{description}
649
650The units in the output file can be changed using the \np{nn\_ucf} namelist parameter.
651For example, in case of salinity tendency the units are given by PSU/s/\np{nn\_ucf}.
652Setting \np{nn\_ucf}=86400 ($i.e.$ the number of second in a day) provides the tendencies in PSU/d.
653
654When \key{trdmld} is defined, two time averaging procedure are proposed.
655Setting \np{ln\_trdmld\_instant} to \textit{true}, a simple time averaging is performed,
656so that the resulting tendency is the contribution to the change of a quantity between
657the two instantaneous values taken at the extremities of the time averaging period.
658Setting \np{ln\_trdmld\_instant} to \textit{false}, a double time averaging is performed,
659so that the resulting tendency is the contribution to the change of a quantity between
660two \textit{time mean} values. The later option requires the use of an extra file, \ifile{restart\_mld} 
661(\np{ln\_trdmld\_restart}=true), to restart a run.
662
663
664Note that the mixed layer tendency diagnostic can also be used on biogeochemical models
665via the \key{trdtrc} and \key{trdmld\_trc} CPP keys.
666
667% -------------------------------------------------------------------------------------------------------------
668%       On-line Floats trajectories
669% -------------------------------------------------------------------------------------------------------------
670\section{On-line Floats trajectories (FLO) (\key{floats})}
671\label{FLO}
672%--------------------------------------------namflo-------------------------------------------------------
673\namdisplay{namflo} 
674%--------------------------------------------------------------------------------------------------------------
675
676The on-line computation of floats advected either by the three dimensional velocity
677field or constraint to remain at a given depth ($w = 0$ in the computation) have been
678introduced in the system during the CLIPPER project. Options are defined by \ngn{namflo}
679namelis variables. The algorithm used is based
680either on the work of \cite{Blanke_Raynaud_JPO97} (default option), or on a $4^th$
681Runge-Hutta algorithm (\np{ln\_flork4}=true). Note that the \cite{Blanke_Raynaud_JPO97} 
682algorithm have the advantage of providing trajectories which are consistent with the
683numeric of the code, so that the trajectories never intercept the bathymetry.
684
685\subsubsection{ Input data: initial coordinates }
686
687Initial coordinates can be given with Ariane Tools convention ( IJK coordinates ,(\np{ln\_ariane}=true) )
688or with longitude and latitude.
689
690
691In case of Ariane convention, input filename is \np{init\_float\_ariane}. Its format is:
692
693\texttt{ I J K nisobfl itrash itrash }
694
695\noindent with:
696
697 - I,J,K  : indexes of initial position
698
699 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity 
700
701 - itrash : set to zero; it is a dummy variable to respect Ariane Tools convention
702
703 - itrash :set to zero; it is a dummy variable to respect Ariane Tools convention
704
705\noindent Example:\\
706\noindent \texttt{ 100.00000  90.00000  -1.50000 1.00000   0.00000}\\
707\texttt{ 102.00000  90.00000  -1.50000 1.00000   0.00000}\\
708\texttt{ 104.00000  90.00000  -1.50000 1.00000   0.00000}\\
709\texttt{ 106.00000  90.00000  -1.50000 1.00000   0.00000}\\
710\texttt{ 108.00000  90.00000  -1.50000 1.00000   0.00000}\\
711
712
713In the other case ( longitude and latitude ), input filename is init\_float. Its format is:
714
715\texttt{ Long Lat depth nisobfl ngrpfl itrash}
716
717\noindent with:
718
719 - Long, Lat, depth  : Longitude, latitude, depth
720
721 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity
722
723 - ngrpfl : number to identify searcher group
724
725 - itrash :set to 1; it is a dummy variable.
726
727\noindent Example:
728
729\noindent\texttt{  20.0 0.0 0.0 0 1 1 }\\
730\texttt{ -21.0 0.0 0.0 0 1 1 }\\
731\texttt{ -22.0 0.0 0.0 0 1 1 }\\
732\texttt{ -23.0 0.0 0.0 0 1 1 }\\
733\texttt{ -24.0 0.0 0.0 0 1 1 }\\
734
735\np{jpnfl} is the total number of floats during the run.
736When initial positions are read in a restart file ( \np{ln\_rstflo}= .TRUE. ),  \np{jpnflnewflo}
737can be added in the initialization file.
738
739\subsubsection{ Output data }
740
741\np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} 
742is the frequency of creation of the float restart file.
743
744Output data can be written in ascii files (\np{ln\_flo\_ascii} = .TRUE. ). In that case,
745output filename is trajec\_float.
746
747Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii} = .FALSE. ). There are 2 possibilities:
748
749 - if (\key{iomput}) is used, outputs are selected in  iodef.xml. Here it is an example of specification
750   to put in files description section:
751
752\vspace{-30pt}
753\begin{alltt}  {{\scriptsize
754\begin{verbatim}
755
756     <group id="1d\_grid\_T" name="auto" description="ocean T grid variables" >   }
757       <file id="floats"  description="floats variables"> }\\
758           <field ref="traj\_lon"   name="floats\_longitude"   freq\_op="86400" />}
759           <field ref="traj\_lat"   name="floats\_latitude"    freq\_op="86400" />}
760           <field ref="traj\_dep"   name="floats\_depth"       freq\_op="86400" />}
761           <field ref="traj\_temp"  name="floats\_temperature" freq\_op="86400" />}
762           <field ref="traj\_salt"  name="floats\_salinity"    freq\_op="86400" />}
763           <field ref="traj\_dens"  name="floats\_density"     freq\_op="86400" />}
764           <field ref="traj\_group" name="floats\_group"       freq\_op="86400" />}
765       </file>}
766  </group>}
767
768\end{verbatim}
769}}\end{alltt}
770
771
772 -  if (\key{iomput}) is not used, a file called trajec\_float.nc will be created by IOIPSL library.
773
774
775
776See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing
777the off-line use of this marvellous diagnostic tool.
778
779
780% -------------------------------------------------------------------------------------------------------------
781%       Harmonic analysis of tidal constituents
782% -------------------------------------------------------------------------------------------------------------
783\section{Harmonic analysis of tidal constituents (\key{diaharm}) }
784\label{DIA_diag_harm}
785
786A module is available to compute the amplitude and phase for tidal waves.
787This diagnostic is actived with \key{diaharm}.
788
789%------------------------------------------namdia_harm----------------------------------------------------
790\namdisplay{namdia_harm}
791%----------------------------------------------------------------------------------------------------------
792
793Concerning the on-line Harmonic analysis, some parameters are available in namelist
794\ngn{namdia\_harm} :
795
796- \texttt{nit000\_han} is the first time step used for harmonic analysis
797
798- \texttt{nitend\_han} is the last time step used for harmonic analysis
799
800- \texttt{nstep\_han} is the time step frequency for harmonic analysis
801
802- \texttt{nb\_ana} is the number of harmonics to analyse
803
804- \texttt{tname} is an array with names of tidal constituents to analyse
805
806\texttt{nit000\_han} and \texttt{nitend\_han} must be between \texttt{nit000} and \texttt{nitend} of the simulation.
807The restart capability is not implemented.
808
809The Harmonic analysis solve this equation:
810\begin{equation}
811h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[A_{j}cos(\nu_{j}t_{j}-\phi_{j})] = e_{i}
812\end{equation}
813
814With $A_{j}$,$\nu_{j}$,$\phi_{j}$, the amplitude, frequency and phase for each wave and $e_{i}$ the error.
815$h_{i}$ is the sea level for the time $t_{i}$ and $A_{0}$ is the mean sea level. \\
816We can rewrite this equation:
817\begin{equation}
818h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[C_{j}cos(\nu_{j}t_{j})+S_{j}sin(\nu_{j}t_{j})] = e_{i}
819\end{equation}
820with $A_{j}=\sqrt{C^{2}_{j}+S^{2}_{j}}$ et $\phi_{j}=arctan(S_{j}/C_{j})$.
821
822We obtain in output $C_{j}$ and $S_{j}$ for each tidal wave.
823
824% -------------------------------------------------------------------------------------------------------------
825%       Sections transports
826% -------------------------------------------------------------------------------------------------------------
827\section{Transports across sections (\key{diadct}) }
828\label{DIA_diag_dct}
829
830A module is available to compute the transport of volume, heat and salt through sections. This diagnostic
831is actived with \key{diadct}.
832
833Each section is defined by the coordinates of its 2 extremities. The pathways between them are contructed
834using tools which can be found in  \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT} and are written in a binary file
835 \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by NEMO to compute on-line transports.
836
837The on-line transports module creates three output ascii files:
838
839- \texttt{volume\_transport} for volume transports (  unit: $10^{6} m^{3} s^{-1}$ )
840
841- \texttt{heat\_transport}   for heat transports   (  unit: $10^{15} W $ )
842
843- \texttt{salt\_transport}   for salt transports   (  unit: $10^{9}Kg s^{-1}$ )\\
844
845
846Namelist variables in \ngn{namdct} control how frequently the flows are summed
847and the time scales over which they are averaged, as well as the level of output for debugging:
848
849%------------------------------------------namdct----------------------------------------------------
850\namdisplay{namdct}
851%-------------------------------------------------------------------------------------------------------------
852
853\texttt{nn\_dct}: frequency of instantaneous transports computing
854
855\texttt{nn\_dctwri}: frequency of writing ( mean of instantaneous transports )
856
857\texttt{nn\_debug}: debugging of the section
858
859\subsubsection{ To create a binary file containing the pathway of each section }
860
861In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run}, the file \texttt{ {list\_sections.ascii\_global}}
862contains a list of all the sections that are to be computed (this list of sections is based on MERSEA project metrics).
863
864Another file is available for the GYRE configuration (\texttt{ {list\_sections.ascii\_GYRE}}).
865
866Each section is defined by:
867
868\noindent \texttt{ long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name }\\
869with:
870
871- \texttt{long1 lat1} , coordinates of the first extremity of the section;
872
873- \texttt{long2 lat2} , coordinates of the second extremity of the section;
874
875- \texttt{nclass} the number of bounds of your classes (e.g. 3 bounds for 2 classes);
876
877- \texttt{okstrpond} to compute heat and salt transport, \texttt{nostrpond} if no;
878
879- \texttt{ice}  to compute surface and volume ice transports, \texttt{noice} if no. \\
880
881
882\noindent The results of the computing of transports, and the directions of positive
883 and negative flow do not depend on the order of the 2 extremities in this file.\\ 
884
885
886\noindent If nclass =/ 0,the next lines contain the class type and the nclass bounds:
887
888\texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}
889
890\texttt{classtype}
891
892\texttt{zbound1}
893
894\texttt{zbound2}
895
896\texttt{.}
897
898\texttt{.}
899
900\texttt{nclass-1}
901
902\texttt{nclass}
903
904\noindent where \texttt{classtype} can be:
905
906- \texttt{zsal} for salinity classes
907
908- \texttt{ztem} for temperature classes
909
910- \texttt{zlay} for depth classes
911
912- \texttt{zsigi} for insitu density classes
913
914- \texttt{zsigp} for potential density classes \\
915
916 
917The script \texttt{job.ksh} computes the pathway for each section and creates a binary file
918\texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\
919
920It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated
921with the coordinates file name and path. \\
922
923
924Examples of two sections, the ACC\_Drake\_Passage with no classes, and the
925 ATL\_Cuba\_Florida with 4 temperature clases (5 class bounds), are shown:
926
927\noindent \texttt{ -68.    -54.5   -60.    -64.7  00 okstrpond noice ACC\_Drake\_Passage}
928
929\noindent \texttt{ -80.5    22.5   -80.5    25.5  05 nostrpond noice ATL\_Cuba\_Florida}
930
931\noindent \texttt{ztem}
932
933\noindent \texttt{-2.0}
934
935\noindent \texttt{ 4.5}
936
937\noindent \texttt{ 7.0}
938
939\noindent \texttt{12.0}
940
941\noindent \texttt{40.0}
942
943
944\subsubsection{ To read the output files }
945
946The output format is :
947 
948{\small\texttt{date, time-step number, section number, section name, section slope coefficient, class number,
949class name, class bound 1 , classe bound2, transport\_direction1 ,  transport\_direction2, transport\_total}}\\
950
951
952For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for each class
953and the last line corresponds to the total transport summed over all classes. For sections with no classes, class number
954\texttt{ 1 } corresponds to \texttt{ total class } and this class is called  \texttt{N}, meaning \texttt{none}.\\
955
956
957\noindent \texttt{ transport\_direction1 } is the positive part of the transport ( \texttt{ > = 0 } ).
958
959\noindent \texttt{ transport\_direction2 } is the negative part of the transport ( \texttt{ < = 0 } ).\\
960
961
962\noindent The \texttt{section slope coefficient} gives information about the significance of transports signs and direction:\\
963
964
965
966\begin{tabular}{|c|c|c|c|p{4cm}|}
967\hline
968section slope coefficient & section type & direction 1 & direction 2 & total transport \\ \hline
9690.    &  horizontal & northward & southward & postive: northward  \\ \hline
9701000. &  vertical   & eastward  & westward  & postive: eastward  \\ \hline               
971\texttt{=/0, =/ 1000.}   &  diagonal   & eastward  & westward  & postive: eastward  \\ \hline               
972\end{tabular}
973
974
975
976% -------------------------------------------------------------------------------------------------------------
977%       Other Diagnostics
978% -------------------------------------------------------------------------------------------------------------
979\section{Other Diagnostics (\key{diahth}, \key{diaar5})}
980\label{DIA_diag_others}
981
982
983Aside from the standard model variables, other diagnostics can be computed
984on-line. The available ready-to-add diagnostics routines can be found in directory DIA.
985Among the available diagnostics the following ones are obtained when defining
986the \key{diahth} CPP key:
987
988- the mixed layer depth (based on a density criterion, \citet{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth})
989
990- the turbocline depth (based on a turbulent mixing coefficient criterion) (\mdl{diahth})
991
992- the depth of the 20\deg C isotherm (\mdl{diahth})
993
994- the depth of the thermocline (maximum of the vertical temperature gradient) (\mdl{diahth})
995
996The poleward heat and salt transports, their advective and diffusive component, and
997the meriodional stream function can be computed on-line in \mdl{diaptr} 
998\np{ln\_diaptr} to true (see the \textit{\ngn{namptr} } namelist below). 
999When \np{ln\_subbas}~=~true, transports and stream function are computed
1000for the Atlantic, Indian, Pacific and Indo-Pacific Oceans (defined north of 30\deg S)
1001as well as for the World Ocean. The sub-basin decomposition requires an input file
1002(\ifile{subbasins}) which contains three 2D mask arrays, the Indo-Pacific mask
1003been deduced from the sum of the Indian and Pacific mask (Fig~\ref{Fig_mask_subasins}).
1004
1005%------------------------------------------namptr----------------------------------------------------
1006\namdisplay{namptr} 
1007%-------------------------------------------------------------------------------------------------------------
1008%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1009\begin{figure}[!t]     \begin{center}
1010\includegraphics[width=1.0\textwidth]{./TexFiles/Figures/Fig_mask_subasins.pdf}
1011\caption{   \label{Fig_mask_subasins}
1012Decomposition of the World Ocean (here ORCA2) into sub-basin used in to compute
1013the heat and salt transports as well as the meridional stream-function: Atlantic basin (red),
1014Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green).
1015Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay
1016are removed from the sub-basins. Note also that the Arctic Ocean has been split
1017into Atlantic and Pacific basins along the North fold line.  }
1018\end{center}   \end{figure} 
1019%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1020
1021In addition, a series of diagnostics has been added in the \mdl{diaar5}.
1022They corresponds to outputs that are required for AR5 simulations
1023(see Section \ref{DIA_steric} below for one of them).
1024Activating those outputs requires to define the \key{diaar5} CPP key.
1025\\
1026\\
1027
1028
1029
1030% ================================================================
1031% Steric effect in sea surface height
1032% ================================================================
1033\section{Diagnosing the Steric effect in sea surface height}
1034\label{DIA_steric}
1035
1036
1037Changes in steric sea level are caused when changes in the density of the water
1038column imply an expansion or contraction of the column. It is essentially produced
1039through surface heating/cooling and to a lesser extent through non-linear effects of
1040the equation of state (cabbeling, thermobaricity...).
1041Non-Boussinesq models contain all ocean effects within the ocean acting
1042on the sea level. In particular, they include the steric effect. In contrast,
1043Boussinesq models, such as \NEMO, conserve volume, rather than mass,
1044and so do not properly represent expansion or contraction. The steric effect is
1045therefore not explicitely represented.
1046This approximation does not represent a serious error with respect to the flow field
1047calculated by the model \citep{Greatbatch_JGR94}, but extra attention is required
1048when investigating sea level, as steric changes are an important
1049contribution to local changes in sea level on seasonal and climatic time scales.
1050This is especially true for investigation into sea level rise due to global warming.
1051
1052Fortunately, the steric contribution to the sea level consists of a spatially uniform
1053component that can be diagnosed by considering the mass budget of the world
1054ocean \citep{Greatbatch_JGR94}.
1055In order to better understand how global mean sea level evolves and thus how
1056the steric sea level can be diagnosed, we compare, in the following, the
1057non-Boussinesq and Boussinesq cases.
1058
1059Let denote
1060$\mathcal{M}$ the total mass of liquid seawater ($\mathcal{M}=\int_D \rho dv$),
1061$\mathcal{V}$ the total volume of seawater ($\mathcal{V}=\int_D dv$),
1062$\mathcal{A}$ the total surface of the ocean ($\mathcal{A}=\int_S ds$),
1063$\bar{\rho}$ the global mean seawater (\textit{in situ}) density ($\bar{\rho}= 1/\mathcal{V} \int_D \rho \,dv$), and
1064$\bar{\eta}$ the global mean sea level ($\bar{\eta}=1/\mathcal{A}\int_S \eta \,ds$).
1065
1066A non-Boussinesq fluid conserves mass. It satisfies the following relations:
1067\begin{equation} \label{Eq_MV_nBq} 
1068\begin{split} 
1069\mathcal{M} &\mathcal{V}  \;\bar{\rho}       \\
1070\mathcal{V} &\mathcal{A}  \;\bar{\eta} 
1071\end{split}
1072\end{equation}
1073Temporal changes in total mass is obtained from the density conservation equation :
1074\begin{equation}  \label{Eq_Co_nBq}
1075\frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} ) = \left. \frac{\textit{emp}}{e_3}\right|_\textit{surface}
1076\end{equation}
1077where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass
1078exchanges with the other media of the Earth system (atmosphere, sea-ice, land).
1079Its global averaged leads to the total mass change
1080\begin{equation}  \label{Eq_Mass_nBq}
1081\partial_t \mathcal{M} = \mathcal{A} \;\overline{\textit{emp}}
1082\end{equation}
1083where $\overline{\textit{emp}}=\int_S \textit{emp}\,ds$ is the net mass flux
1084through the ocean surface.
1085Bringing \eqref{Eq_Mass_nBq} and the time derivative of \eqref{Eq_MV_nBq} 
1086together leads to the evolution equation of the mean sea level
1087\begin{equation} \label{Eq_ssh_nBq}
1088  \partial_t \bar{\eta} =  \frac{\overline{\textit{emp}}}{ \bar{\rho}} 
1089               - \frac{\mathcal{V}}{\mathcal{A}}  \;\frac{\partial_t \bar{\rho} }{\bar{\rho}}
1090\end{equation}
1091The first term in equation \eqref{Eq_ssh_nBq} alters sea level by adding or
1092subtracting mass from the ocean.
1093The second term arises from temporal changes in the global mean
1094density; $i.e.$ from steric effects.
1095
1096In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ 
1097appears multiplied by the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations).
1098In particular, the mass conservation equation, \eqref{Eq_Co_nBq}, degenerates into
1099the incompressibility equation:
1100\begin{equation}  \label{Eq_Co_Bq}
1101\frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) =  \left. \frac{\textit{emp}}{\rho_o \,e_3}\right|_ \textit{surface}
1102\end{equation}
1103and the global average of this equation now gives the temporal change of the total volume,
1104\begin{equation}  \label{Eq_V_Bq}
1105  \partial_t \mathcal{V} =   \mathcal{A} \;\frac{\overline{\textit{emp}}}{\rho_o} 
1106\end{equation}
1107Only the volume is conserved, not mass, or, more precisely, the mass which is conserved is the
1108Boussinesq mass, $\mathcal{M}_o = \rho_o \mathcal{V}$. The total volume (or equivalently 
1109the global mean sea level) is altered only by net volume fluxes across the ocean surface, 
1110not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid.
1111 
1112Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be
1113diagnosed by considering the mass budget of the ocean.
1114The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface
1115mass flux must be compensated by a spatially uniform change in the mean sea level due to
1116expansion/contraction of the ocean \citep{Greatbatch_JGR94}. In others words, the Boussinesq
1117mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$, the  total mass of the ocean seen
1118by the Boussinesq model, via the steric contribution to the sea level, $\eta_s$, a spatially
1119uniform variable, as follows:
1120\begin{equation}  \label{Eq_M_Bq}
1121   \mathcal{M}_o  =  \mathcal{M} + \rho_o \,\eta_s \,\mathcal{A} 
1122\end{equation}
1123Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through
1124the ocean surface is converted into a mean change in sea level. Introducing the total density
1125anomaly, $\mathcal{D}= \int_D d_a \,dv$, where $d_a= (\rho -\rho_o ) / \rho_o$ 
1126is the density anomaly used in \NEMO (cf. \S\ref{TRA_eos}) in \eqref{Eq_M_Bq}
1127leads to a very simple form for the steric height:
1128\begin{equation}  \label{Eq_steric_Bq}
1129   \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D} 
1130\end{equation}
1131
1132The above formulation of the steric height of a Boussinesq ocean requires four remarks.
1133First, one can be tempted to define $\rho_o$ as the initial value of $\mathcal{M}/\mathcal{V}$,
1134$i.e.$ set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero. We do not
1135recommend that. Indeed, in this case $\rho_o$ depends on the initial state of the ocean.
1136Since $\rho_o$ has a direct effect on the dynamics of the ocean (it appears in the pressure
1137gradient term of the momentum equation) it is definitively not a good idea when
1138inter-comparing experiments.
1139We better recommend to fixe once for all $\rho_o$ to $1035\;Kg\,m^{-3}$. This value is a
1140sensible choice for the reference density used in a Boussinesq ocean climate model since,
1141with the exception of only a small percentage of the ocean, density in the World Ocean
1142varies by no more than 2$\%$ from this value (\cite{Gill1982}, page 47).
1143
1144Second, we have assumed here that the total ocean surface, $\mathcal{A}$, does not
1145change when the sea level is changing as it is the case in all global ocean GCMs
1146(wetting and drying of grid point is not allowed).
1147 
1148Third, the discretisation of \eqref{Eq_steric_Bq} depends on the type of free surface
1149which is considered. In the non linear free surface case, $i.e.$ \key{vvl} defined, it is
1150given by
1151\begin{equation}  \label{Eq_discrete_steric_Bq}
1152   \eta_s =  - \frac{ \sum_{i,\,j,\,k} d_a\; e_{1t} e_{2t} e_{3t} }
1153                  { \sum_{i,\,j,\,k}         e_{1t} e_{2t} e_{3t} } 
1154\end{equation}
1155whereas in the linear free surface, the volume above the \textit{z=0} surface must be explicitly taken
1156into account to better approximate the total ocean mass and thus the steric sea level:
1157\begin{equation}  \label{Eq_discrete_steric_Bq}
1158   \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 }
1159                     {\sum_{i,\,j,\,k} e_{1t}e_{2t}e_{3t} + \sum_{i,\,j}           e_{1t}e_{2t} \eta } 
1160\end{equation}
1161
1162The fourth and last remark concerns the effective sea level and the presence of sea-ice.
1163In the real ocean, sea ice (and snow above it)  depresses the liquid seawater through
1164its mass loading. This depression is a result of the mass of sea ice/snow system acting
1165on the liquid ocean. There is, however, no dynamical effect associated with these depressions
1166in the liquid ocean sea level, so that there are no associated ocean currents. Hence, the
1167dynamically relevant sea level is the effective sea level, $i.e.$ the sea level as if sea ice
1168(and snow) were converted to liquid seawater \citep{Campin_al_OM08}. However,
1169in the current version of \NEMO the sea-ice is levitating above the ocean without
1170mass exchanges between ice and ocean. Therefore the model effective sea level
1171is always given by $\eta + \eta_s$, whether or not there is sea ice present.
1172
1173In AR5 outputs, the thermosteric sea level is demanded. It is steric sea level due to
1174changes in ocean density arising just from changes in temperature. It is given by:
1175\begin{equation}  \label{Eq_thermosteric_Bq}
1176   \eta_s = - \frac{1}{\mathcal{A}} \int_D d_a(T,S_o,p_o) \,dv
1177\end{equation}
1178where $S_o$ and $p_o$ are the initial salinity and pressure, respectively.
1179
1180Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs
1181the \key{diaar5} defined to be called.
1182
1183% ================================================================
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
Note: See TracBrowser for help on using the repository browser.