Ignore:
Timestamp:
2018-11-21T17:59:55+01:00 (2 years ago)
Author:
nicolasmartin
Message:

Vast edition of LaTeX subfiles to improve the readability by cutting sentences in a more suitable way
Every sentence begins in a new line and if necessary is splitted around 110 characters lenght for side-by-side visualisation,
this setting may not be adequate for everyone but something has to be set.
The punctuation was the primer trigger for the cutting process, otherwise subordinators and coordinators, in order to mostly keep a meaning for each line

File:
1 edited

Legend:

Unmodified
Added
Removed
  • NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex

    r10146 r10354  
    1717\label{sec:DIA_io_old} 
    1818 
    19 The model outputs are of three types: the restart file, the output listing, and  
    20 the diagnostic output file(s). 
    21 The restart file is used internally by the code when the user wants to start the model with  
     19The model outputs are of three types: the restart file, the output listing, and the diagnostic output file(s). 
     20The restart file is used internally by the code when the user wants to start the model with 
    2221initial conditions defined by a previous simulation. 
    23 It contains all the information that is necessary in order for there to be no changes in  
    24 the model results (even at the computer precision) between a run performed with several restarts and  
     22It contains all the information that is necessary in order for there to be no changes in the model results 
     23(even at the computer precision) between a run performed with several restarts and 
    2524the same run performed in one step. 
    26 It should be noted that this requires that the restart file contains two consecutive time steps for  
    27 all the prognostic variables, and that it is saved in the same binary format as the one used by  
    28 the computer that is to read it (in particular, 32 bits binary IEEE format must not be used for this file). 
    29  
    30 The output listing and file(s) are predefined but should be checked and eventually adapted to  
    31 the user's needs. 
     25It should be noted that this requires that the restart file contains two consecutive time steps for 
     26all the prognostic variables, and that it is saved in the same binary format as the one used by the computer that 
     27is to read it (in particular, 32 bits binary IEEE format must not be used for this file). 
     28 
     29The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs. 
    3230The output listing is stored in the $ocean.output$ file. 
    3331The information is printed from within the code on the logical unit $numout$. 
     
    3533 
    3634By default, diagnostic output files are written in NetCDF format. 
    37 Since version 3.2, when defining \key{iomput}, an I/O server has been added which  
    38 provides more flexibility in the choice of the fields to be written as well as  
    39 how the writing work is distributed over the processors in massively parallel computing.  
    40 A complete description of the use of this I/O server is presented in the next section.  
    41  
    42 By default, \key{iomput} is not defined, NEMO produces NetCDF with the old IOIPSL library which  
    43 has been kept for compatibility and its easy installation. 
    44 However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2,  
    45 many diagnostic options have been added presuming the use of \key{iomput}.  
    46 The usefulness of the default IOIPSL-based option is expected to reduce with each new release.  
    47 If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and  
    48 contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of  
     35Since version 3.2, when defining \key{iomput}, an I/O server has been added which 
     36provides more flexibility in the choice of the fields to be written as well as how 
     37the writing work is distributed over the processors in massively parallel computing. 
     38A complete description of the use of this I/O server is presented in the next section. 
     39 
     40By default, \key{iomput} is not defined, 
     41NEMO produces NetCDF with the old IOIPSL library which has been kept for compatibility and its easy installation. 
     42However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2, 
     43many diagnostic options have been added presuming the use of \key{iomput}. 
     44The usefulness of the default IOIPSL-based option is expected to reduce with each new release. 
     45If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and 
     46contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of 
    4947nn\_write time-steps (namelist parameter).  
    5048 
     
    5755\label{sec:DIA_iom} 
    5856 
    59 Since version 3.2, iomput is the NEMO output interface of choice.  
    60 It has been designed to be simple to use, flexible and efficient.  
     57Since version 3.2, iomput is the NEMO output interface of choice. 
     58It has been designed to be simple to use, flexible and efficient. 
    6159The two main purposes of iomput are:  
    6260 
    6361\begin{enumerate} 
    64    \item The complete and flexible control of the output files through external XML files adapted by  
    65          the user from standard templates. 
    66    \item To achieve high performance and scalable output through the optional distribution of  
    67          all diagnostic output related tasks to dedicated processes. 
     62\item 
     63  The complete and flexible control of the output files through external XML files adapted by 
     64  the user from standard templates. 
     65\item 
     66  To achieve high performance and scalable output through the optional distribution of 
     67  all diagnostic output related tasks to dedicated processes. 
    6868\end{enumerate} 
    6969 
     
    7272 
    7373\begin{itemize} 
    74    \item The choice of output frequencies that can be different for each file  
    75          (including real months and years). 
    76    \item The choice of file contents; includes complete flexibility over which data are written in  
    77          which files (the same data can be written in different files). 
    78    \item The possibility to split output files at a chosen frequency. 
    79    \item The possibility to extract a vertical or an horizontal subdomain. 
    80    \item The choice of the temporal operation to perform,  
    81          e.g.: average, accumulate, instantaneous, min, max and once. 
    82    \item Control over metadata via a large XML "database" of possible output fields. 
     74\item 
     75  The choice of output frequencies that can be different for each file (including real months and years). 
     76\item 
     77  The choice of file contents; includes complete flexibility over which data are written in which files 
     78  (the same data can be written in different files). 
     79\item 
     80  The possibility to split output files at a chosen frequency. 
     81\item 
     82  The possibility to extract a vertical or an horizontal subdomain. 
     83\item 
     84  The choice of the temporal operation to perform, $e.g.$: average, accumulate, instantaneous, min, max and once. 
     85\item 
     86  Control over metadata via a large XML "database" of possible output fields. 
    8387\end{itemize} 
    8488 
    85 In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or  
    86 3D) in a very easy way. 
     89In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or 3D) 
     90in a very easy way. 
    8791All details of iomput functionalities are listed in the following subsections. 
    88 Examples of the XML files that control the outputs can be found in:  
    89 \path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml}, \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and  
    90 \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}. \\ 
     92Examples of the XML files that control the outputs can be found in: \path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml}, 
     93\path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}. \\ 
    9194 
    9295The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). 
    93 Iomput provides the possibility to specify N dedicated I/O processes (in addition to  
    94 the NEMO processes) to collect and write the outputs. 
    95 With an appropriate choice of N by the user, the bottleneck associated with the writing of  
     96Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) 
     97to collect and write the outputs. 
     98With an appropriate choice of N by the user, the bottleneck associated with the writing of 
    9699the output files can be greatly reduced. 
    97100 
    98 In version 3.6, the iom\_put interface depends on an external code called  
    99 \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0}  
     101In version 3.6, the iom\_put interface depends on 
     102an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0}  
    100103(use of revision 618 or higher is required). 
    101 This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to  
     104This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to 
    102105create a single output file and therefore to bypass the rebuilding phase. 
    103 Note that writing in parallel into the same NetCDF files requires that  
    104 your NetCDF4 library is linked to an HDF5 library that has been correctly compiled ($i.e.$ with  
    105 the configure option $--$enable-parallel). 
     106Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to 
     107an HDF5 library that has been correctly compiled ($i.e.$ with the configure option $--$enable-parallel). 
    106108Note that the files created by iomput through XIOS are incompatible with NetCDF3. 
    107 All post-processsing and visualization tools must therefore be compatible with  
    108 NetCDF4 and not only NetCDF3. 
    109  
    110 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers,  
    111 where N is typically much less than the number of NEMO processors,  
    112 will reduce the number of output files created. 
    113 This can greatly reduce the post-processing burden usually associated with using  
    114 large numbers of NEMO processors. 
    115 Note that for smaller configurations, the rebuilding phase can be avoided, even without  
    116 a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 
     109All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 
     110 
     111Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, 
     112where N is typically much less than the number of NEMO processors, will reduce the number of output files created. 
     113This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. 
     114Note that for smaller configurations, the rebuilding phase can be avoided, 
     115even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 
    117116 
    118117\subsection{XIOS: XML Inputs-Outputs Server} 
     
    120119\subsubsection{Attached or detached mode?} 
    121120 
    122 Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS},  
     121Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, 
    123122the io\_server developed by Yann Meurdesoif from IPSL. 
    124123The behaviour of the I/O subsystem is controlled by settings in the external XML files listed above. 
     
    127126\xmlline|<variable id="using_server" type="bool"></variable>| 
    128127 
    129 The {\tt using\_server} setting determines whether or not the server will be used in  
    130 \textit{attached mode} (as a library) [{\tt> false <}] or in \textit{detached mode} (as  
    131 an external executable on N additional, dedicated cpus) [{\tt > true <}]. 
     128The {\tt using\_server} setting determines whether or not the server will be used in \textit{attached mode} 
     129(as a library) [{\tt> false <}] or in \textit{detached mode} 
     130(as an external executable on N additional, dedicated cpus) [{\tt > true <}]. 
    132131The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications. 
    133132The type of each file can be either ''multiple\_file'' or ''one\_file''. 
    134133 
    135 In \textit{attached mode} and if the type of file is ''multiple\_file'',  
     134In \textit{attached mode} and if the type of file is ''multiple\_file'', 
    136135then each NEMO process will also act as an IO server and produce its own set of output files. 
    137136Superficially, this emulates the standard behaviour in previous versions. 
    138 However, the subdomain written out by each process does not correspond to  
     137However, the subdomain written out by each process does not correspond to 
    139138the \forcode{jpi x jpj x jpk} domain actually computed by the process (although it may if \forcode{jpni=1}). 
    140139Instead each process will have collected and written out a number of complete longitudinal strips. 
    141 If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and  
     140If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and 
    142141write (in parallel) to a single output file. 
    143142 
    144 In \textit{detached mode} and if the type of file is ''multiple\_file'', then  
    145 each stand-alone XIOS process will collect data for a range of complete longitudinal strips and  
     143In \textit{detached mode} and if the type of file is ''multiple\_file'', 
     144then each stand-alone XIOS process will collect data for a range of complete longitudinal strips and 
    146145write to its own set of output files. 
    147 If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and  
     146If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and 
    148147write (in parallel) to a single output file.  
    149148Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. 
    150 The following subsection provides a typical example but the syntax will vary in  
    151 different MPP environments. 
     149The following subsection provides a typical example but the syntax will vary in different MPP environments. 
    152150 
    153151\subsubsection{Number of cpu used by XIOS in detached mode} 
     
    156154The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of  
    157155cores dedicated to NEMO. 
    158 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but  
     156Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but 
    159157this is a general recommendation and not specific to NEMO. 
    160 It is difficult to provide precise recommendations because the optimal choice will depend on  
     158It is difficult to provide precise recommendations because the optimal choice will depend on 
    161159the particular hardware properties of the target system  
    162 (parallel filesystem performance, available memory, memory bandwidth etc.) and  
    163 the volume and frequency of data to be created. 
     160(parallel filesystem performance, available memory, memory bandwidth etc.) 
     161and the volume and frequency of data to be created. 
    164162Here is an example of 2 cpus for the io\_server and 62 cpu for nemo using mpirun: 
    165163\cmd|mpirun -np 62 ./nemo.exe : -np 2 ./xios_server.exe| 
     
    167165\subsubsection{Control of XIOS: the context in iodef.xml} 
    168166 
    169 As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in  
    170 the XIOS context in iodef.xml. 
     167As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. 
    171168See the XML basics section below for more details on XML syntax and rules. 
    172169 
     
    205202\subsubsection{Installation} 
    206203 
    207 As mentioned, XIOS is supported separately and must be downloaded and compiled before  
    208 it can be used with NEMO. 
    209 See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for  
    210 help and guidance. 
     204As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. 
     205See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. 
    211206NEMO will need to link to the compiled XIOS library. 
    212 The  
    213 \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS} 
    214 {XIOS with NEMO} 
    215 guide provides an example illustration of how this can be achieved. 
     207The \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS} 
     208{XIOS with NEMO} guide provides an example illustration of how this can be achieved. 
    216209 
    217210\subsubsection{Add your own outputs} 
    218211 
    219212It is very easy to add your own outputs with iomput. 
    220 Many standard fields and diagnostics are already prepared ($i.e.$, steps 1 to 3 below have been done) and  
     213Many standard fields and diagnostics are already prepared ($i.e.$, steps 1 to 3 below have been done) and 
    221214simply need to be activated by including the required output in a file definition in iodef.xml (step 4). 
    222215To add new output variables, all 4 of the following steps must be taken. 
    223216 
    224217\begin{enumerate} 
    225    \item[1.] in NEMO code, add a \forcode{CALL iom\_put( 'identifier', array )} where you want to  
    226                output a 2D or 3D array. 
    227    \item[2.] If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in  
    228                the upper part of your module. 
    229    \item[3.] in the field\_def.xml file, add the definition of your variable using  
    230                the same identifier you used in the f90 code (see subsequent sections for  
    231                a details of the XML syntax and rules). 
    232 For example: 
     218\item[1.] 
     219  in NEMO code, add a \forcode{CALL iom\_put( 'identifier', array )} where you want to output a 2D or 3D array. 
     220\item[2.] 
     221  If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in 
     222  the upper part of your module. 
     223\item[3.] 
     224  in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code 
     225  (see subsequent sections for a details of the XML syntax and rules). 
     226  For example: 
    233227 
    234228\begin{xmllines} 
     
    241235\end{xmllines} 
    242236 
    243 Note your definition must be added to the field\_group whose reference grid is consistent with  
    244 the size of the array passed to iomput. 
    245 The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids and  
    246 axes either defined in the code (iom\_set\_domain\_attr and iom\_set\_axis\_attr in \mdl{iom}) or  
    247 defined in the domain\_def.xml file. 
     237Note your definition must be added to the field\_group whose reference grid is consistent with the size of 
     238the array passed to iomput. 
     239The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, 
     240reference grids and axes either defined in the code 
     241(iom\_set\_domain\_attr and iom\_set\_axis\_attr in \mdl{iom}) or defined in the domain\_def.xml file. 
    248242$e.g.$: 
    249243 
     
    252246\end{xmllines} 
    253247 
    254 Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step,  
     248Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step, 
    255249add the field definition within the field\_group defined with the id "SBC": 
    256 \xmlcode{<field_group id="SBC" ...>} which has been defined with the correct frequency of  
    257 operations (iom\_set\_field\_attr in \mdl{iom}) 
    258    \item[4.] add your field in one of the output files defined in iodef.xml  
    259 (again see subsequent sections for syntax and rules) 
     250\xmlcode{<field_group id="SBC" ...>} which has been defined with the correct frequency of operations 
     251(iom\_set\_field\_attr in \mdl{iom}) 
     252\item[4.] 
     253  add your field in one of the output files defined in iodef.xml 
     254  (again see subsequent sections for syntax and rules) 
    260255 
    261256\begin{xmllines} 
     
    274269 
    275270XML tags begin with the less-than character ("$<$") and end with the greater-than character ("$>$"). 
    276 You use tags to mark the start and end of elements, which are the logical units of information in  
    277 an XML document. 
    278 In addition to marking the beginning of an element, XML start tags also provide a place to  
    279 specify attributes. 
    280 An attribute specifies a single property for an element, using a name/value pair, for example:  
     271You use tags to mark the start and end of elements, which are the logical units of information in an XML document. 
     272In addition to marking the beginning of an element, XML start tags also provide a place to specify attributes. 
     273An attribute specifies a single property for an element, using a name/value pair, for example: 
    281274\xmlcode{<a b="x" c="y" d="z"> ... </a>}. 
    282275See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details. 
     
    284277\subsubsection{Structure of the XML file used in NEMO} 
    285278 
    286 The XML file used in XIOS is structured by 7 families of tags:  
     279The XML file used in XIOS is structured by 7 families of tags: 
    287280context, axis, domain, grid, field, file and variable. 
    288281Each tag family has hierarchy of three flavors (except for context): 
     
    302295 
    303296Each element may have several attributes. 
    304 Some attributes are mandatory, other are optional but have a default value and  
    305 other are completely optional. 
     297Some attributes are mandatory, other are optional but have a default value and other are completely optional. 
    306298Id is a special attribute used to identify an element or a group of elements. 
    307299It must be unique for a kind of element. 
    308300It is optional, but no reference to the corresponding element can be done if it is not defined. 
    309301 
    310 The XML file is split into context tags that are used to isolate IO definition from different codes or  
    311 different parts of a code. 
     302The XML file is split into context tags that are used to isolate IO definition from 
     303different codes or different parts of a code. 
    312304No interference is possible between 2 different contexts. 
    313305Each context has its own calendar and an associated timestep. 
     
    370362  
    371363\noindent In NEMO, by default, the field and domain definition is done in 2 separate files: 
    372 \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}  
    373 that are included in the main iodef.xml file through the following commands: 
     364\path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml} that 
     365are included in the main iodef.xml file through the following commands: 
    374366\begin{xmllines} 
    375367<field_definition src="./field_def.xml" /> 
     
    380372 
    381373XML extensively uses the concept of inheritance. 
    382 XML has a tree based structure with a parent-child oriented relation:  
    383 all children inherit attributes from parent, but an attribute defined in a child replace  
    384 the inherited attribute value.  
    385 Note that the special attribute ''id'' is never inherited. \\ \\ 
     374XML has a tree based structure with a parent-child oriented relation: all children inherit attributes from parent, 
     375but an attribute defined in a child replace the inherited attribute value. 
     376Note that the special attribute ''id'' is never inherited. 
     377\\ 
     378\\ 
    386379example 1: Direct inheritance. 
    387380 
     
    393386\end{xmllines} 
    394387 
    395 The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average''  
    396 of the attribute ''operation'' from its parent. 
     388The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average'' of 
     389the attribute ''operation'' from its parent. 
    397390Note that a child can overwrite the attribute definition inherited from its parents. 
    398 In the example above, the field ''sss'' will for example output instantaneous values instead of  
    399 average values. \\ \\ 
     391In the example above, the field ''sss'' will for example output instantaneous values instead of average values. 
     392\\ 
     393\\ 
    400394example 2: Inheritance by reference. 
    401395 
     
    418412 
    419413Groups can be used for 2 purposes. 
    420 Firstly, the group can be used to define common attributes to be shared by the elements of  
     414Firstly, the group can be used to define common attributes to be shared by the elements of 
    421415the group through inheritance. 
    422416In the following example, we define a group of field that will share a common grid ''grid\_T\_2D''. 
    423 Note that for the field ''toce'', we overwrite the grid definition inherited from the group by  
    424 ''grid\_T\_3D''. 
     417Note that for the field ''toce'', we overwrite the grid definition inherited from the group by ''grid\_T\_3D''. 
    425418 
    426419\begin{xmllines} 
     
    456449\subsection{Detailed functionalities} 
    457450 
    458 The file \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml} provides several examples of the use of  
     451The file \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml} provides several examples of the use of 
    459452the new functionalities offered by the XML interface of XIOS. 
    460453 
    461454\subsubsection{Define horizontal subdomains} 
    462455 
    463 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of  
     456Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of 
    464457the tag family domain. 
    465458It must therefore be done in the domain part of the XML file.  
     
    472465\end{xmllines} 
    473466 
    474 The use of this subdomain is done through the redefinition of the attribute domain\_ref of  
    475 the tag family field. 
     467The use of this subdomain is done through the redefinition of the attribute domain\_ref of the tag family field. 
    476468For example: 
    477469 
     
    483475 
    484476Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain.  
    485 The Equatorial section, the TAO, RAMA and PIRATA moorings are alredy registered in the code and  
     477The Equatorial section, the TAO, RAMA and PIRATA moorings are already registered in the code and 
    486478can therefore be outputted without taking care of their (i,j) position in the grid. 
    487479These predefined domains can be activated by the use of specific domain\_ref: 
    488 ''EqT'', ''EqU'' or ''EqW'' for the equatorial sections and the mooring position for  
    489 TAO, RAMA and PIRATA followed by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...) 
     480''EqT'', ''EqU'' or ''EqW'' for the equatorial sections and 
     481the mooring position for TAO, RAMA and PIRATA followed by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...) 
    490482 
    491483\begin{xmllines} 
     
    503495\subsubsection{Define vertical zooms} 
    504496 
    505 Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis.  
    506 It must therefore be done in the axis part of the XML file.  
     497Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis. 
     498It must therefore be done in the axis part of the XML file. 
    507499For example, in \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml}, we provide the following example: 
    508500 
     
    513505\end{xmllines} 
    514506 
    515 The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of  
    516 the tag family field. 
     507The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of the tag family field. 
    517508For example: 
    518509 
     
    539530\end{xmllines} 
    540531 
    541 However it is often very convienent to define the file name with the name of the experiment,  
    542 the output file frequency and the date of the beginning and the end of the simulation  
     532However it is often very convienent to define the file name with the name of the experiment, 
     533the output file frequency and the date of the beginning and the end of the simulation 
    543534(which are informations stored either in the namelist or in the XML file). 
    544 To do so, we added the following rule: if the id of the tag file is ''fileN'' (where N = 1 to 999 on  
    545 1 to 3 digits) or one of the predefined sections or moorings (see next subsection),  
    546 the following part of the name and the name\_suffix (that can be inherited) will be automatically  
    547 replaced by: 
     535To do so, we added the following rule: 
     536if the id of the tag file is ''fileN'' (where N = 1 to 999 on 1 to 3 digits) or 
     537one of the predefined sections or moorings (see next subsection), 
     538the following part of the name and the name\_suffix (that can be inherited) will be automatically replaced by: 
    548539 
    549540\begin{table} \scriptsize 
     
    580571\end{forlines} 
    581572 
    582 \noindent will give the following file name radical: 
    583 \ifile{myfile\_ORCA2\_19891231\_freq1d} 
     573\noindent will give the following file name radical: \ifile{myfile\_ORCA2\_19891231\_freq1d} 
    584574 
    585575\subsubsection{Other controls of the XML attributes from NEMO} 
    586576 
    587577The values of some attributes are defined by subroutine calls within NEMO  
    588 (calls to iom\_set\_domain\_attr, iom\_set\_axis\_attr and iom\_set\_field\_attr in \mdl{iom}).  
    589 Any definition given in the XML file will be overwritten.  
    590 By convention, these attributes are defined to ''auto'' (for string) or ''0000'' (for integer) in  
    591 the XML file (but this is not necessary). \\ 
    592  
    593 Here is the list of these attributes: \\ 
     578(calls to iom\_set\_domain\_attr, iom\_set\_axis\_attr and iom\_set\_field\_attr in \mdl{iom}). 
     579Any definition given in the XML file will be overwritten. 
     580By convention, these attributes are defined to ''auto'' (for string) or ''0000'' (for integer) in the XML file 
     581(but this is not necessary). 
     582\\ 
     583 
     584Here is the list of these attributes: 
     585\\ 
    594586 
    595587\begin{table} \scriptsize 
     
    631623 
    632624\begin{enumerate} 
    633 \item Simple computation: directly define the computation when refering to the variable in  
    634 the file definition. 
     625\item 
     626  Simple computation: directly define the computation when refering to the variable in the file definition. 
    635627 
    636628\begin{xmllines} 
     
    640632\end{xmllines} 
    641633 
    642 \item Simple computation: define a new variable and use it in the file definition. 
     634\item 
     635  Simple computation: define a new variable and use it in the file definition. 
    643636 
    644637in field\_definition: 
     
    654647\end{xmllines} 
    655648 
    656 Note that in this case, the following syntaxe \xmlcode{<field field_ref="sst2" />} is not working as  
     649Note that in this case, the following syntaxe \xmlcode{<field field_ref="sst2" />} is not working as 
    657650sst2 won't be evaluated. 
    658651 
    659 \item Change of variable precision: 
     652\item 
     653  Change of variable precision: 
    660654 
    661655\begin{xmllines} 
     
    667661 
    668662Note that, then the code is crashing, writting real4 variables forces a numerical convection from  
    669 real8 to real4 which will create an internal error in NetCDF and will avoid the creation of  
    670 the output files. 
    671 Forcing double precision outputs with prec="8" (for example in the field\_definition) will  
    672 avoid this problem. 
    673  
    674 \item add user defined attributes: 
     663real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. 
     664Forcing double precision outputs with prec="8" (for example in the field\_definition) will avoid this problem. 
     665 
     666\item 
     667  add user defined attributes: 
    675668 
    676669\begin{xmllines} 
     
    687680\end{xmllines} 
    688681 
    689 \item use of the ``@'' function: example 1, weighted temporal average 
     682\item 
     683  use of the ``@'' function: example 1, weighted temporal average 
    690684 
    691685 - define a new variable in field\_definition 
     
    706700 
    707701The freq\_op="5d" attribute is used to define the operation frequency of the ``@'' function: here 5 day. 
    708 The temporal operation done by the ``@'' is the one defined in the field definition:  
     702The temporal operation done by the ``@'' is the one defined in the field definition: 
    709703here we use the default, average. 
    710704So, in the above case, @toce\_e3t will do the 5-day mean of toce*e3t. 
    711 Operation="instant" refers to the temporal operation to be performed on the field''@toce\_e3t / @e3t'':  
    712 here the temporal average is alreday done by the ``@'' function so we just use instant to do the ratio of  
     705Operation="instant" refers to the temporal operation to be performed on the field''@toce\_e3t / @e3t'': 
     706here the temporal average is alreday done by the ``@'' function so we just use instant to do the ratio of 
    713707the 2 mean values. 
    714708field\_ref="toce" means that attributes not explicitely defined, are inherited from toce field. 
    715709Note that in this case, freq\_op must be equal to the file output\_freq. 
    716710 
    717 \item use of the ``@'' function: example 2, monthly SSH standard deviation 
     711\item 
     712  use of the ``@'' function: example 2, monthly SSH standard deviation 
    718713 
    719714 - define a new variable in field\_definition 
     
    737732 
    738733The freq\_op="1m" attribute is used to define the operation frequency of the ``@'' function: here 1 month. 
    739 The temporal operation done by the ``@'' is the one defined in the field definition:  
     734The temporal operation done by the ``@'' is the one defined in the field definition: 
    740735here we use the default, average. 
    741736So, in the above case, @ssh2 will do the monthly mean of ssh*ssh. 
    742 Operation="instant" refers to the temporal operation to be performed on  
    743 the field ''sqrt( @ssh2 - @ssh * @ssh )'':  
     737Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'':  
    744738here the temporal average is alreday done by the ``@'' function so we just use instant. 
    745739field\_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field. 
    746740Note that in this case, freq\_op must be equal to the file output\_freq. 
    747741 
    748 \item use of the ``@'' function: example 3, monthly average of SST diurnal cycle 
     742\item 
     743  use of the ``@'' function: example 3, monthly average of SST diurnal cycle 
    749744 
    750745 - define 2 new variables in field\_definition 
     
    770765 
    771766The freq\_op="1d" attribute is used to define the operation frequency of the ``@'' function: here 1 day. 
    772 The temporal operation done by the ``@'' is the one defined in the field definition: here maximum for  
    773 sstmax and minimum for sstmin. 
     767The temporal operation done by the ``@'' is the one defined in the field definition: 
     768here maximum for sstmax and minimum for sstmin. 
    774769So, in the above case, @sstmax will do the daily max and @sstmin the daily min. 
    775 Operation="average" refers to the temporal operation to be performed on the field ``@sstmax - @sstmin'':  
     770Operation="average" refers to the temporal operation to be performed on the field ``@sstmax - @sstmin'': 
    776771here monthly mean (of daily max - daily min of the sst). 
    777772field\_ref="sst" means that attributes not explicitely defined, are inherited from sst field. 
     
    11261121 
    11271122Output from the XIOS-1.0 IO server is compliant with  
    1128 \href{http://cfconventions.org/Data/cf-conventions/cf-conventions-1.5/build/cf-conventions.html}{version 1.5}  
    1129 of the CF metadata standard.  
    1130 Therefore while a user may wish to add their own metadata to the output files (as demonstrated in  
    1131 example 4 of section \autoref{subsec:IOM_xmlref}) the metadata should, for the most part, comply with  
    1132 the CF-1.5 standard. 
    1133  
    1134 Some metadata that may significantly increase the file size (horizontal cell areas and  
    1135 vertices) are controlled by the namelist parameter \np{ln\_cfmeta} in the \ngn{namrun} namelist. 
     1123\href{http://cfconventions.org/Data/cf-conventions/cf-conventions-1.5/build/cf-conventions.html}{version 1.5} of 
     1124the CF metadata standard.  
     1125Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of 
     1126section \autoref{subsec:IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard. 
     1127 
     1128Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by 
     1129the namelist parameter \np{ln\_cfmeta} in the \ngn{namrun} namelist. 
    11361130This must be set to true if these metadata are to be included in the output files. 
    11371131 
     
    11441138 
    11451139Since version 3.3, support for NetCDF4 chunking and (loss-less) compression has been included. 
    1146 These options build on the standard NetCDF output and allow the user control over the size of  
    1147 the chunks via namelist settings. 
     1140These options build on the standard NetCDF output and allow the user control over the size of the chunks via 
     1141namelist settings. 
    11481142Chunking and compression can lead to significant reductions in file sizes for a small runtime overhead. 
    1149 For a fuller discussion on chunking and other performance issues the reader is referred to  
    1150 the NetCDF4 documentation found  
    1151 \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}. 
    1152  
    1153 The new features are only available when the code has been linked with a NetCDF4 library  
    1154 (version 4.1 onwards, recommended) which has been built with HDF5 support  
    1155 (version 1.8.4 onwards, recommended). 
    1156 Datasets created with chunking and compression are not backwards compatible with  
    1157 NetCDF3 "classic" format but most analysis codes can be relinked simply with the new libraries and  
    1158 will then read both NetCDF3 and NetCDF4 files. 
    1159 NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by  
     1143For a fuller discussion on chunking and other performance issues the reader is referred to 
     1144the NetCDF4 documentation found \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}. 
     1145 
     1146The new features are only available when the code has been linked with a NetCDF4 library 
     1147(version 4.1 onwards, recommended) which has been built with HDF5 support (version 1.8.4 onwards, recommended). 
     1148Datasets created with chunking and compression are not backwards compatible with NetCDF3 "classic" format but 
     1149most analysis codes can be relinked simply with the new libraries and will then read both NetCDF3 and NetCDF4 files. 
     1150NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by 
    11601151setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} namelist: 
    11611152 
     
    11661157 
    11671158If \key{netcdf4} has not been defined, these namelist parameters are not read. 
    1168 In this case, \np{ln\_nc4zip} is set false and dummy routines for  
    1169 a few NetCDF4-specific functions are defined. 
    1170 These functions will not be used but need to be included so that compilation is possible with  
    1171 NetCDF3 libraries. 
    1172  
    1173 When using NetCDF4 libraries, \key{netcdf4} should be defined even if the intention is to  
     1159In this case, \np{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined. 
     1160These functions will not be used but need to be included so that compilation is possible with NetCDF3 libraries. 
     1161 
     1162When using NetCDF4 libraries, \key{netcdf4} should be defined even if the intention is to 
    11741163create only NetCDF3-compatible files. 
    1175 This is necessary to avoid duplication between the dummy routines and  
    1176 the actual routines present in the library. 
     1164This is necessary to avoid duplication between the dummy routines and the actual routines present in the library. 
    11771165Most compilers will fail at compile time when faced with such duplication. 
    1178 Thus when linking with NetCDF4 libraries the user must define \key{netcdf4} and  
     1166Thus when linking with NetCDF4 libraries the user must define \key{netcdf4} and 
    11791167control the type of NetCDF file produced via the namelist parameter. 
    11801168 
    1181 Chunking and compression is applied only to 4D fields and there is no advantage in  
    1182 chunking across more than one time dimension since previously written chunks would have to  
    1183 be read back and decompressed before being added to. 
     1169Chunking and compression is applied only to 4D fields and 
     1170there is no advantage in chunking across more than one time dimension since 
     1171previously written chunks would have to be read back and decompressed before being added to. 
    11841172Therefore, user control over chunk sizes is provided only for the three space dimensions. 
    11851173The user sets an approximate number of chunks along each spatial axis. 
    1186 The actual size of the chunks will depend on global domain size for mono-processors or,  
    1187 more likely, the local processor domain size for distributed processing. 
    1188 The derived values are subject to practical minimum values (to avoid wastefully small chunk sizes) and  
     1174The actual size of the chunks will depend on global domain size for mono-processors or, more likely, 
     1175the local processor domain size for distributed processing. 
     1176The derived values are subject to practical minimum values (to avoid wastefully small chunk sizes) and 
    11891177cannot be greater than the domain size in any dimension. 
    11901178The algorithm used is: 
     
    12031191\end{forlines} 
    12041192 
    1205 \noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\tt 46x38x1} respectively in  
     1193\noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\tt 46x38x1} respectively in 
    12061194the mono-processor case (i.e. global domain of {\small\tt 182x149x31}). 
    12071195An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in  
    1208 table \autoref{tab:NC4} which compares the results of two short runs of  
    1209 the ORCA2\_LIM reference configuration with a 4x2 mpi partitioning. 
    1210 Note the variation in the compression ratio achieved which reflects chiefly the dry to  
    1211 wet volume ratio of each processing region. 
     1196table \autoref{tab:NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with 
     1197a 4x2 mpi partitioning. 
     1198Note the variation in the compression ratio achieved which reflects chiefly the dry to wet volume ratio of 
     1199each processing region. 
    12121200 
    12131201%------------------------------------------TABLE---------------------------------------------------- 
     
    12491237%---------------------------------------------------------------------------------------------------- 
    12501238 
    1251 When \key{iomput} is activated with \key{netcdf4} chunking and compression parameters for  
    1252 fields produced via \np{iom\_put} calls are set via an equivalent and identically named namelist to  
    1253 \textit{namnc4} in \np{xmlio\_server.def}. 
    1254 Typically this namelist serves the mean files whilst the \ngn{ namnc4} in  
    1255 the main namelist file continues to serve the restart files. 
    1256 This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of  
    1257 the individual files produced by the io\_server processes may be different to those produced by  
     1239When \key{iomput} is activated with \key{netcdf4} chunking and compression parameters for fields produced via 
     1240\np{iom\_put} calls are set via an equivalent and identically named namelist to \textit{namnc4} in 
     1241\np{xmlio\_server.def}. 
     1242Typically this namelist serves the mean files whilst the \ngn{ namnc4} in the main namelist file continues to 
     1243serve the restart files. 
     1244This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of 
     1245the individual files produced by the io\_server processes may be different to those produced by 
    12581246the invidual processing regions and different chunking choices may be desired. 
    12591247  
     
    12691257%------------------------------------------------------------------------------------------------------------- 
    12701258 
    1271 Each trend of the dynamics and/or temperature and salinity time evolution equations can be send to  
    1272 \mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation ($i.e.$ at  
    1273 the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). 
     1259Each trend of the dynamics and/or temperature and salinity time evolution equations can be send to 
     1260\mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation 
     1261($i.e.$ at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). 
    12741262This capability is controlled by options offered in \ngn{namtrd} namelist. 
    12751263Note that the output are done with xIOS, and therefore the \key{IOM} is required. 
     
    12781266 
    12791267\begin{description} 
    1280    \item[\np{ln\_glo\_trd}]: at each \np{nn\_trd} time-step a check of the basin averaged properties of  
    1281                               the momentum and tracer equations is performed. 
    1282                               This also includes a check of $T^2$, $S^2$, $\tfrac{1}{2} (u^2+v2)$, and  
    1283                               potential energy time evolution equations properties; 
    1284    \item[\np{ln\_dyn\_trd}]: each 3D trend of the evolution of the two momentum components is output; 
    1285    \item[\np{ln\_dyn\_mxl}]: each 3D trend of the evolution of the two momentum components averaged over  
    1286                               the mixed layer is output; 
    1287    \item[\np{ln\_vor\_trd}]: a vertical summation of the moment tendencies is performed, then  
    1288                               the curl is computed to obtain the barotropic vorticity tendencies which  
    1289                               are output; 
    1290    \item[\np{ln\_KE\_trd}] : each 3D trend of the Kinetic Energy equation is output ; 
    1291    \item[\np{ln\_tra\_trd}]: each 3D trend of the evolution of temperature and salinity is output ; 
    1292    \item[\np{ln\_tra\_mxl}]: each 2D trend of the evolution of temperature and salinity averaged over  
    1293                               the mixed layer is output; 
     1268\item[\np{ln\_glo\_trd}]: 
     1269  at each \np{nn\_trd} time-step a check of the basin averaged properties of 
     1270  the momentum and tracer equations is performed. 
     1271  This also includes a check of $T^2$, $S^2$, $\tfrac{1}{2} (u^2+v2)$, 
     1272  and potential energy time evolution equations properties; 
     1273\item[\np{ln\_dyn\_trd}]: 
     1274  each 3D trend of the evolution of the two momentum components is output; 
     1275\item[\np{ln\_dyn\_mxl}]: 
     1276  each 3D trend of the evolution of the two momentum components averaged over the mixed layer is output; 
     1277\item[\np{ln\_vor\_trd}]: 
     1278  a vertical summation of the moment tendencies is performed, 
     1279  then the curl is computed to obtain the barotropic vorticity tendencies which are output; 
     1280\item[\np{ln\_KE\_trd}] : 
     1281  each 3D trend of the Kinetic Energy equation is output; 
     1282\item[\np{ln\_tra\_trd}]: 
     1283  each 3D trend of the evolution of temperature and salinity is output; 
     1284\item[\np{ln\_tra\_mxl}]: 
     1285  each 2D trend of the evolution of temperature and salinity averaged over the mixed layer is output; 
    12941286\end{description} 
    12951287 
     
    12981290 
    12991291\textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested. 
    1300 In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are  
    1301 not working, and none of the options have been tested with variable volume ($i.e.$ \key{vvl} defined). 
     1292In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are not working, 
     1293and none of the options have been tested with variable volume ($i.e.$ \key{vvl} defined). 
    13021294 
    13031295% ------------------------------------------------------------------------------------------------------------- 
     
    13111303%-------------------------------------------------------------------------------------------------------------- 
    13121304 
    1313 The on-line computation of floats advected either by the three dimensional velocity field or  
    1314 constraint to remain at a given depth ($w = 0$ in the computation) have been introduced in  
    1315 the system during the CLIPPER project. 
     1305The on-line computation of floats advected either by the three dimensional velocity field or constraint to 
     1306remain at a given depth ($w = 0$ in the computation) have been introduced in the system during the CLIPPER project. 
    13161307Options are defined by \ngn{namflo} namelis variables. 
    1317 The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option), or  
    1318 on a $4^th$ Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}). 
    1319 Note that the \cite{Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which  
     1308The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option), 
     1309or on a $4^th$ Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}). 
     1310Note that the \cite{Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which 
    13201311are consistent with the numeric of the code, so that the trajectories never intercept the bathymetry. 
    13211312 
    13221313\subsubsection{Input data: initial coordinates} 
    13231314 
    1324 Initial coordinates can be given with Ariane Tools convention (IJK coordinates, 
    1325 (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude. 
     1315Initial coordinates can be given with Ariane Tools convention 
     1316(IJK coordinates, (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude. 
    13261317 
    13271318In case of Ariane convention, input filename is \np{init\_float\_ariane}. 
     
    13681359 
    13691360\np{jpnfl} is the total number of floats during the run. 
    1370 When initial positions are read in a restart file (\np{ln\_rstflo}\forcode{ = .true.} ),  
     1361When initial positions are read in a restart file (\np{ln\_rstflo}\forcode{ = .true.} ), 
    13711362\np{jpnflnewflo} can be added in the initialization file. 
    13721363 
    13731364\subsubsection{Output data} 
    13741365 
    1375 \np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} is  
    1376 the frequency of creation of the float restart file. 
     1366\np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} is the frequency of 
     1367creation of the float restart file. 
    13771368 
    13781369Output data can be written in ascii files (\np{ln\_flo\_ascii}\forcode{ = .true.}). 
     
    13821373There are 2 possibilities: 
    13831374 
    1384  - if (\key{iomput}) is used, outputs are selected in  iodef.xml. 
    1385    Here it is an example of specification to put in files description section: 
     1375- if (\key{iomput}) is used, outputs are selected in  iodef.xml. 
     1376Here it is an example of specification to put in files description section: 
    13861377 
    13871378\begin{xmllines} 
     
    14011392 -  if (\key{iomput}) is not used, a file called \ifile{trajec\_float} will be created by IOIPSL library. 
    14021393 
    1403 See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing  
    1404 the off-line use of this marvellous diagnostic tool. 
     1394 See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing the off-line use of 
     1395 this marvellous diagnostic tool. 
    14051396 
    14061397% ------------------------------------------------------------------------------------------------------------- 
     
    14181409This on-line Harmonic analysis is actived with \key{diaharm}. 
    14191410 
    1420 Some parameters are available in namelist \ngn{namdia\_harm} : 
     1411Some parameters are available in namelist \ngn{namdia\_harm}: 
    14211412 
    14221413 - \np{nit000\_han} is the first time step used for harmonic analysis 
     
    14301421 - \np{tname}       is an array with names of tidal constituents to analyse 
    14311422 
    1432 \np{nit000\_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation. 
    1433 The restart capability is not implemented. 
    1434  
    1435 The Harmonic analysis solve the following equation: 
     1423 \np{nit000\_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation. 
     1424 The restart capability is not implemented. 
     1425 
     1426 The Harmonic analysis solve the following equation: 
    14361427 
    14371428\[h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[A_{j}cos(\nu_{j}t_{j}-\phi_{j})] = e_{i}\] 
    14381429 
    1439 With $A_{j}$, $\nu_{j}$, $\phi_{j}$, the amplitude, frequency and phase for each wave and  
    1440 $e_{i}$ the error. 
     1430With $A_{j}$, $\nu_{j}$, $\phi_{j}$, the amplitude, frequency and phase for each wave and $e_{i}$ the error. 
    14411431$h_{i}$ is the sea level for the time $t_{i}$ and $A_{0}$ is the mean sea level. \\ 
    14421432We can rewrite this equation: 
     
    14591449%------------------------------------------------------------------------------------------------------------- 
    14601450 
    1461 A module is available to compute the transport of volume, heat and salt through sections.  
     1451A module is available to compute the transport of volume, heat and salt through sections. 
    14621452This diagnostic is actived with \key{diadct}. 
    14631453 
    14641454Each section is defined by the coordinates of its 2 extremities. 
    1465 The pathways between them are contructed using tools which can be found in  
    1466 \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT}  
    1467 and are written in a binary file  
    1468 \texttt{section\_ijglobal.diadct\_ORCA2\_LIM}  
    1469 which is later read in by NEMO to compute on-line transports. 
     1455The pathways between them are contructed using tools which can be found in \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT} 
     1456and are written in a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by 
     1457NEMO to compute on-line transports. 
    14701458 
    14711459The on-line transports module creates three output ascii files: 
     
    14771465- \texttt{salt\_transport}   for   salt transports (unit: $10^{9}Kg s^{-1}$) \\ 
    14781466 
    1479 Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over  
    1480 which they are averaged, as well as the level of output for debugging: 
     1467Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over which 
     1468they are averaged, as well as the level of output for debugging: 
    14811469\np{nn\_dct}   : frequency of instantaneous transports computing 
    14821470\np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports ) 
     
    14851473\subsubsection{Creating a binary file containing the pathway of each section} 
    14861474 
    1487 In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run},  
    1488 the file \textit{ {list\_sections.ascii\_global}} contains a list of all the sections that are to  
    1489 be computed (this list of sections is based on MERSEA project metrics). 
     1475In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run}, 
     1476the file \textit{ {list\_sections.ascii\_global}} contains a list of all the sections that are to be computed 
     1477(this list of sections is based on MERSEA project metrics). 
    14901478 
    14911479Another file is available for the GYRE configuration (\texttt{ {list\_sections.ascii\_GYRE}}). 
     
    15051493 - \texttt{ice}       to compute surface and volume ice transports, \texttt{noice}     if no. \\ 
    15061494 
    1507 \noindent The results of the computing of transports, and the directions of positive and  
    1508 negative flow do not depend on the order of the 2 extremities in this file. \\ 
    1509  
    1510 \noindent If nclass $\neq$ 0,the next lines contain the class type and the nclass bounds: \\ 
     1495 \noindent The results of the computing of transports, and the directions of positive and 
     1496 negative flow do not depend on the order of the 2 extremities in this file. \\ 
     1497 
     1498\noindent If nclass $\neq$ 0, the next lines contain the class type and the nclass bounds: \\ 
    15111499{\scriptsize \texttt{ 
    15121500long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name \\ 
     
    15311519 - \texttt{zsigp} for potential density classes \\ 
    15321520   
    1533 The script \texttt{job.ksh} computes the pathway for each section and  
    1534 creates a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\ 
    1535  
    1536 It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated with  
    1537 the coordinates file name and path. \\ 
    1538  
    1539 Examples of two sections, the ACC\_Drake\_Passage with no classes, and the ATL\_Cuba\_Florida with  
    1540 4 temperature clases (5 class bounds), are shown: \\ 
     1521 The script \texttt{job.ksh} computes the pathway for each section and creates a binary file 
     1522 \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\ 
     1523 
     1524 It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated with 
     1525 the coordinates file name and path. \\ 
     1526 
     1527 Examples of two sections, the ACC\_Drake\_Passage with no classes, 
     1528 and the ATL\_Cuba\_Florida with 4 temperature clases (5 class bounds), are shown: \\ 
    15411529\noindent {\scriptsize \texttt{ 
    15421530-68.    -54.5   -60.    -64.7  00 okstrpond noice ACC\_Drake\_Passage \\ 
     
    15591547transport\_total}}                                     \\ 
    15601548 
    1561 For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for  
    1562 each class and the last line corresponds to the total transport summed over all classes. 
    1563 For sections with no classes, class number \texttt{1} corresponds to \texttt{total class} and  
     1549For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for each class and 
     1550the last line corresponds to the total transport summed over all classes. 
     1551For sections with no classes, class number \texttt{1} corresponds to \texttt{total class} and 
    15641552this class is called \texttt{N}, meaning \texttt{none}. 
    15651553 
     
    15681556- \texttt{transport\_direction2} is the negative part of the transport ($\leq$ 0). \\ 
    15691557 
    1570 \noindent The \texttt{section slope coefficient} gives information about the significance of  
    1571 transports signs and direction: \\ 
     1558\noindent The \texttt{section slope coefficient} gives information about the significance of transports signs and 
     1559direction: \\ 
    15721560 
    15731561\begin{table} \scriptsize 
     
    15911579 
    15921580 
    1593 Changes in steric sea level are caused when changes in the density of the water column imply an  
    1594 expansion or contraction of the column. 
    1595 It is essentially produced through surface heating/cooling and to a lesser extent through  
    1596 non-linear effects of the equation of state (cabbeling, thermobaricity...). 
     1581Changes in steric sea level are caused when changes in the density of the water column imply an expansion or 
     1582contraction of the column. 
     1583It is essentially produced through surface heating/cooling and to a lesser extent through non-linear effects of 
     1584the equation of state (cabbeling, thermobaricity...). 
    15971585Non-Boussinesq models contain all ocean effects within the ocean acting on the sea level. 
    15981586In particular, they include the steric effect. 
    1599 In contrast, Boussinesq models, such as \NEMO, conserve volume, rather than mass,  
     1587In contrast, Boussinesq models, such as \NEMO, conserve volume, rather than mass, 
    16001588and so do not properly represent expansion or contraction. 
    16011589The steric effect is therefore not explicitely represented. 
    1602 This approximation does not represent a serious error with respect to the flow field calculated by  
    1603 the model \citep{Greatbatch_JGR94}, but extra attention is required when investigating sea level,  
    1604 as steric changes are an important contribution to local changes in sea level on seasonal and  
    1605 climatic time scales. 
    1606 This is especially true for investigation into sea level rise due to global warming.  
    1607  
    1608 Fortunately, the steric contribution to the sea level consists of a spatially uniform component that  
     1590This approximation does not represent a serious error with respect to the flow field calculated by the model 
     1591\citep{Greatbatch_JGR94}, but extra attention is required when investigating sea level, 
     1592as steric changes are an important contribution to local changes in sea level on seasonal and climatic time scales. 
     1593This is especially true for investigation into sea level rise due to global warming. 
     1594 
     1595Fortunately, the steric contribution to the sea level consists of a spatially uniform component that 
    16091596can be diagnosed by considering the mass budget of the world ocean \citep{Greatbatch_JGR94}. 
    1610 In order to better understand how global mean sea level evolves and thus how the steric sea level can  
    1611 be diagnosed, we compare, in the following, the non-Boussinesq and Boussinesq cases. 
     1597In order to better understand how global mean sea level evolves and thus how the steric sea level can be diagnosed, 
     1598we compare, in the following, the non-Boussinesq and Boussinesq cases. 
    16121599 
    16131600Let denote 
     
    16281615\] 
    16291616 
    1630 Temporal changes in total mass is obtained from the density conservation equation : 
     1617Temporal changes in total mass is obtained from the density conservation equation: 
    16311618 
    16321619\[ \frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} )  
     
    16341621 \label{eq:Co_nBq} \] 
    16351622 
    1636 where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass  
    1637 exchanges with the other media of the Earth system (atmosphere, sea-ice, land).  
     1623where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass exchanges with the other media of 
     1624the Earth system (atmosphere, sea-ice, land). 
    16381625Its global averaged leads to the total mass change  
    16391626 
     
    16421629 
    16431630where $\overline{\textit{emp}} = \int_S \textit{emp}\,ds$ is the net mass flux through the ocean surface. 
    1644 Bringing \autoref{eq:Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to  
     1631Bringing \autoref{eq:Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to 
    16451632the evolution equation of the mean sea level 
    16461633 
     
    16491636 \label{eq:ssh_nBq} \] 
    16501637 
    1651 The first term in equation \autoref{eq:ssh_nBq} alters sea level by adding or  
    1652 subtracting mass from the ocean.  
    1653 The second term arises from temporal changes in the global mean density; $i.e.$ from steric effects.  
    1654  
    1655 In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when  
    1656 $\rho$ appears multiplied by the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations). 
    1657 In particular, the mass conservation equation, \autoref{eq:Co_nBq}, degenerates into  
    1658 the incompressibility equation: 
     1638The first term in equation \autoref{eq:ssh_nBq} alters sea level by adding or subtracting mass from the ocean.  
     1639The second term arises from temporal changes in the global mean density; $i.e.$ from steric effects. 
     1640 
     1641In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ appears multiplied by 
     1642the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations). 
     1643In particular, the mass conservation equation, \autoref{eq:Co_nBq}, degenerates into the incompressibility equation: 
    16591644 
    16601645\[ \frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) 
     
    16671652 \label{eq:V_Bq} \] 
    16681653 
    1669 Only the volume is conserved, not mass, or, more precisely, the mass which is conserved is  
    1670 the Boussinesq mass, $\mathcal{M}_o = \rho_o \mathcal{V}$. 
    1671 The total volume (or equivalently the global mean sea level) is altered only by net volume fluxes across  
    1672 the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in  
    1673 a Boussinesq fluid. 
    1674  
    1675 Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by  
     1654Only the volume is conserved, not mass, or, more precisely, the mass which is conserved is the Boussinesq mass, 
     1655$\mathcal{M}_o = \rho_o \mathcal{V}$. 
     1656The total volume (or equivalently the global mean sea level) is altered only by net volume fluxes across 
     1657the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid. 
     1658 
     1659Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by 
    16761660considering the mass budget of the ocean.  
    1677 The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by  
    1678 surface mass flux must be compensated by a spatially uniform change in the mean sea level due to  
    1679 expansion/contraction of the ocean \citep{Greatbatch_JGR94}. 
    1680 In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$,  
    1681 the  total mass of the ocean seen by the Boussinesq model, via the steric contribution to the sea level,  
     1661The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface mass flux 
     1662must be compensated by a spatially uniform change in the mean sea level due to expansion/contraction of the ocean 
     1663\citep{Greatbatch_JGR94}. 
     1664In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$, 
     1665the total mass of the ocean seen by the Boussinesq model, via the steric contribution to the sea level, 
    16821666$\eta_s$, a spatially uniform variable, as follows: 
    16831667 
     
    16851669 \label{eq:M_Bq} \] 
    16861670 
    1687 Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through  
    1688 the ocean surface is converted into a mean change in sea level. 
    1689 Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$, where  
    1690 $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos}) in  
    1691 \autoref{eq:M_Bq} leads to a very simple form for the steric height: 
     1671Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through the ocean surface 
     1672is converted into a mean change in sea level. 
     1673Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$, 
     1674where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos}) 
     1675in \autoref{eq:M_Bq} leads to a very simple form for the steric height: 
    16921676 
    16931677\[ \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D} 
     
    16991683We do not recommend that. 
    17001684Indeed, in this case $\rho_o$ depends on the initial state of the ocean. 
    1701 Since $\rho_o$ has a direct effect on the dynamics of the ocean (it appears in  
    1702 the pressure gradient term of the momentum equation) it is definitively not a good idea when  
    1703 inter-comparing experiments. 
     1685Since $\rho_o$ has a direct effect on the dynamics of the ocean 
     1686(it appears in the pressure gradient term of the momentum equation) 
     1687it is definitively not a good idea when inter-comparing experiments. 
    17041688We better recommend to fixe once for all $\rho_o$ to $1035\;Kg\,m^{-3}$. 
    1705 This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since,  
    1706 with the exception of only a small percentage of the ocean, density in the World Ocean varies by  
    1707 no more than 2$\%$ from this value (\cite{Gill1982}, page 47). 
    1708  
    1709 Second, we have assumed here that the total ocean surface, $\mathcal{A}$, does not change when  
    1710 the sea level is changing as it is the case in all global ocean GCMs  
     1689This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since, 
     1690with the exception of only a small percentage of the ocean, density in the World Ocean varies by no more than 
     16912$\%$ from this value (\cite{Gill1982}, page 47). 
     1692 
     1693Second, we have assumed here that the total ocean surface, $\mathcal{A}$, 
     1694does not change when the sea level is changing as it is the case in all global ocean GCMs 
    17111695(wetting and drying of grid point is not allowed). 
    17121696   
    1713 Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of  
    1714 free surface which is considered. 
     1697Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of free surface which is considered. 
    17151698In the non linear free surface case, $i.e.$ \key{vvl} defined, it is given by 
    17161699 
     
    17191702 \label{eq:discrete_steric_Bq_nfs} \] 
    17201703 
    1721 whereas in the linear free surface, the volume above the \textit{z=0} surface must be explicitly  
    1722 taken into account to better approximate the total ocean mass and thus the steric sea level: 
     1704whereas in the linear free surface, 
     1705the volume above the \textit{z=0} surface must be explicitly taken into account to 
     1706better approximate the total ocean mass and thus the steric sea level: 
    17231707 
    17241708\[ \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 } 
     
    17291713In the real ocean, sea ice (and snow above it)  depresses the liquid seawater through its mass loading. 
    17301714This depression is a result of the mass of sea ice/snow system acting on the liquid ocean. 
    1731 There is, however, no dynamical effect associated with these depressions in the liquid ocean sea level,  
     1715There is, however, no dynamical effect associated with these depressions in the liquid ocean sea level, 
    17321716so that there are no associated ocean currents. 
    1733 Hence, the dynamically relevant sea level is the effective sea level, $i.e.$ the sea level as if  
    1734 sea ice (and snow) were converted to liquid seawater \citep{Campin_al_OM08}. 
    1735 However, in the current version of \NEMO the sea-ice is levitating above the ocean without  
    1736 mass exchanges between ice and ocean. 
    1737 Therefore the model effective sea level is always given by $\eta + \eta_s$,  
    1738 whether or not there is sea ice present. 
     1717Hence, the dynamically relevant sea level is the effective sea level, 
     1718$i.e.$ the sea level as if sea ice (and snow) were converted to liquid seawater \citep{Campin_al_OM08}. 
     1719However, in the current version of \NEMO the sea-ice is levitating above the ocean without mass exchanges between 
     1720ice and ocean. 
     1721Therefore the model effective sea level is always given by $\eta + \eta_s$, whether or not there is sea ice present. 
    17391722 
    17401723In AR5 outputs, the thermosteric sea level is demanded. 
     
    17471730where $S_o$ and $p_o$ are the initial salinity and pressure, respectively. 
    17481731 
    1749 Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs 
    1750 the \key{diaar5} defined to be called. 
     1732Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs the \key{diaar5} defined to 
     1733be called. 
    17511734 
    17521735% ------------------------------------------------------------------------------------------------------------- 
     
    17611744\subsection{Depth of various quantities (\protect\mdl{diahth})} 
    17621745 
    1763 Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key:  
     1746Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key: 
    17641747 
    17651748- the mixed layer depth (based on a density criterion \citep{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth}) 
     
    17821765%----------------------------------------------------------------------------------------- 
    17831766 
    1784 The poleward heat and salt transports, their advective and diffusive component, and  
    1785 the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true  
     1767The poleward heat and salt transports, their advective and diffusive component, 
     1768and the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true 
    17861769(see the \textit{\ngn{namptr} } namelist below). 
    1787 When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic,  
    1788 Indian, Pacific and Indo-Pacific Oceans (defined north of 30\deg S) as well as for the World Ocean. 
    1789 The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains  
    1790 three 2D mask arrays, the Indo-Pacific mask been deduced from the sum of the Indian and  
    1791 Pacific mask (\autoref{fig:mask_subasins}). 
     1770When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic, Indian, 
     1771Pacific and Indo-Pacific Oceans (defined north of 30\deg S) as well as for the World Ocean. 
     1772The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains three 2D mask arrays, 
     1773the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:mask_subasins}). 
    17921774 
    17931775%>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
    1794 \begin{figure}[!t] \begin{center} 
    1795    \includegraphics[width=1.0\textwidth]{Fig_mask_subasins} 
    1796    \caption{   \protect\label{fig:mask_subasins} 
    1797       Decomposition of the World Ocean (here ORCA2) into sub-basin used in to compute the heat and  
    1798       salt transports as well as the meridional stream-function: Atlantic basin (red),  
    1799       Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green). 
    1800       Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay are removed from  
    1801       the sub-basins. Note also that the Arctic Ocean has been split into Atlantic and  
    1802       Pacific basins along the North fold line.} 
     1776\begin{figure}[!t] 
     1777  \begin{center} 
     1778    \includegraphics[width=1.0\textwidth]{Fig_mask_subasins} 
     1779    \caption{  \protect\label{fig:mask_subasins} 
     1780      Decomposition of the World Ocean (here ORCA2) into sub-basin used in to 
     1781      compute the heat and salt transports as well as the meridional stream-function: 
     1782      Atlantic basin (red), Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green). 
     1783      Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay are removed from the sub-basins. 
     1784      Note also that the Arctic Ocean has been split into Atlantic and Pacific basins along the North fold line.} 
    18031785\end{center} \end{figure}   
    18041786%>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
     
    18271809The 25 hour mean is available for daily runs by summing up the 25 hourly instantananeous hourly values from 
    18281810midnight at the start of the day to midight at the day end. 
    1829 This diagnostic is actived with the logical  $ln\_dia25h$ 
     1811This diagnostic is actived with the logical $ln\_dia25h$. 
    18301812 
    18311813% ----------------------------------------------------------- 
     
    18391821%---------------------------------------------------------------------------------------------------------- 
    18401822 
    1841 A module is available to output the surface (top), mid water and bed diagnostics of a set of  
    1842 standard variables. 
    1843 This can be a useful diagnostic when hourly or sub-hourly output is required in  
    1844 high resolution tidal outputs. 
     1823A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables. 
     1824This can be a useful diagnostic when hourly or sub-hourly output is required in high resolution tidal outputs. 
    18451825The tidal signal is retained but the overall data usage is cut to just three vertical levels. 
    18461826Also the bottom level is calculated for each cell. 
    1847 This diagnostic is actived with the logical  $ln\_diatmb$ 
     1827This diagnostic is actived with the logical $ln\_diatmb$. 
    18481828 
    18491829% ----------------------------------------------------------- 
     
    18591839 
    18601840in the zonal, meridional and vertical directions respectively. 
    1861 The vertical component is included although it is not strictly valid as the vertical velocity is  
    1862 calculated from the continuity equation rather than as a prognostic variable. 
     1841The vertical component is included although it is not strictly valid as the vertical velocity is calculated from 
     1842the continuity equation rather than as a prognostic variable. 
    18631843Physically this represents the rate at which information is propogated across a grid cell. 
    1864 Values greater than 1 indicate that information is propagated across more than one grid cell in  
    1865 a single time step. 
    1866  
    1867 The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in  
    1868 the \ngn{namctl} namelist. 
     1844Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step. 
     1845 
     1846The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in the \ngn{namctl} namelist. 
    18691847The diagnostics will be written out to an ascii file named cfl\_diagnostics.ascii. 
    1870 In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with  
    1871 the coordinates of where the maximum value occurs. 
    1872 At the end of the model run the maximum value of $C_u$, $C_v$, and $C_w$ for the whole model run is  
    1873 printed along with the coordinates of each. 
     1848In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with the coordinates of 
     1849where the maximum value occurs. 
     1850At 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 
     1851with the coordinates of each. 
    18741852The maximum values from the run are also copied to the ocean.output file.  
    18751853 
Note: See TracChangeset for help on using the changeset viewer.