Changeset 10368 for NEMO/branches/2018/dev_r10164_HPC09_ESIWACE_PREP_MERGE/doc/latex/NEMO/subfiles/chap_DIA.tex
- Timestamp:
- 2018-12-03T12:45:01+01:00 (5 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
NEMO/branches/2018/dev_r10164_HPC09_ESIWACE_PREP_MERGE/doc/latex/NEMO/subfiles/chap_DIA.tex
r10146 r10368 17 17 \label{sec:DIA_io_old} 18 18 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 19 The model outputs are of three types: the restart file, the output listing, and the diagnostic output file(s). 20 The restart file is used internally by the code when the user wants to start the model with 22 21 initial conditions defined by a previous simulation. 23 It contains all the information that is necessary in order for there to be no changes in 24 the model results (even at the computer precision) between a run performed with several restarts and 22 It 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 25 24 the same run performed in one step. 26 It should be noted that this requires that the restart file contains two consecutive time steps for 27 all the prognostic variables, and that it is saved in the same binary format as the one used by 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. 25 It should be noted that this requires that the restart file contains two consecutive time steps for 26 all the prognostic variables, and that it is saved in the same binary format as the one used by the computer that 27 is to read it (in particular, 32 bits binary IEEE format must not be used for this file). 28 29 The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs. 32 30 The output listing is stored in the $ocean.output$ file. 33 31 The information is printed from within the code on the logical unit $numout$. … … 35 33 36 34 By 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 which43 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 35 Since version 3.2, when defining \key{iomput}, an I/O server has been added which 36 provides more flexibility in the choice of the fields to be written as well as how 37 the writing work is distributed over the processors in massively parallel computing. 38 A complete description of the use of this I/O server is presented in the next section. 39 40 By default, \key{iomput} is not defined, 41 NEMO produces NetCDF with the old IOIPSL library which has been kept for compatibility and its easy installation. 42 However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2, 43 many diagnostic options have been added presuming the use of \key{iomput}. 44 The usefulness of the default IOIPSL-based option is expected to reduce with each new release. 45 If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and 46 contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of 49 47 nn\_write time-steps (namelist parameter). 50 48 … … 57 55 \label{sec:DIA_iom} 58 56 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. 57 Since version 3.2, iomput is the NEMO output interface of choice. 58 It has been designed to be simple to use, flexible and efficient. 61 59 The two main purposes of iomput are: 62 60 63 61 \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. 68 68 \end{enumerate} 69 69 … … 72 72 73 73 \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. 83 87 \end{itemize} 84 88 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.89 In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or 3D) 90 in a very easy way. 87 91 All 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}. \\ 92 Examples 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}. \\ 91 94 92 95 The 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 t he 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 96 Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) 97 to collect and write the outputs. 98 With an appropriate choice of N by the user, the bottleneck associated with the writing of 96 99 the output files can be greatly reduced. 97 100 98 In version 3.6, the iom\_put interface depends on an external code called99 \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0}101 In version 3.6, the iom\_put interface depends on 102 an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0} 100 103 (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 104 This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to 102 105 create 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). 106 Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to 107 an HDF5 library that has been correctly compiled ($i.e.$ with the configure option $--$enable-parallel). 106 108 Note 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. 109 All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 110 111 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, 112 where N is typically much less than the number of NEMO processors, will reduce the number of output files created. 113 This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. 114 Note that for smaller configurations, the rebuilding phase can be avoided, 115 even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 117 116 118 117 \subsection{XIOS: XML Inputs-Outputs Server} … … 120 119 \subsubsection{Attached or detached mode?} 121 120 122 Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, 121 Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, 123 122 the io\_server developed by Yann Meurdesoif from IPSL. 124 123 The behaviour of the I/O subsystem is controlled by settings in the external XML files listed above. … … 127 126 \xmlline|<variable id="using_server" type="bool"></variable>| 128 127 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 <}].128 The {\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 <}]. 132 131 The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications. 133 132 The type of each file can be either ''multiple\_file'' or ''one\_file''. 134 133 135 In \textit{attached mode} and if the type of file is ''multiple\_file'', 134 In \textit{attached mode} and if the type of file is ''multiple\_file'', 136 135 then each NEMO process will also act as an IO server and produce its own set of output files. 137 136 Superficially, this emulates the standard behaviour in previous versions. 138 However, the subdomain written out by each process does not correspond to 137 However, the subdomain written out by each process does not correspond to 139 138 the \forcode{jpi x jpj x jpk} domain actually computed by the process (although it may if \forcode{jpni=1}). 140 139 Instead each process will have collected and written out a number of complete longitudinal strips. 141 If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and 140 If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and 142 141 write (in parallel) to a single output file. 143 142 144 In \textit{detached mode} and if the type of file is ''multiple\_file'', then145 each stand-alone XIOS process will collect data for a range of complete longitudinal strips and 143 In \textit{detached mode} and if the type of file is ''multiple\_file'', 144 then each stand-alone XIOS process will collect data for a range of complete longitudinal strips and 146 145 write to its own set of output files. 147 If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and 146 If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and 148 147 write (in parallel) to a single output file. 149 148 Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. 150 The following subsection provides a typical example but the syntax will vary in 151 different MPP environments. 149 The following subsection provides a typical example but the syntax will vary in different MPP environments. 152 150 153 151 \subsubsection{Number of cpu used by XIOS in detached mode} … … 156 154 The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of 157 155 cores dedicated to NEMO. 158 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but 156 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but 159 157 this is a general recommendation and not specific to NEMO. 160 It is difficult to provide precise recommendations because the optimal choice will depend on 158 It is difficult to provide precise recommendations because the optimal choice will depend on 161 159 the particular hardware properties of the target system 162 (parallel filesystem performance, available memory, memory bandwidth etc.) and163 the volume and frequency of data to be created.160 (parallel filesystem performance, available memory, memory bandwidth etc.) 161 and the volume and frequency of data to be created. 164 162 Here is an example of 2 cpus for the io\_server and 62 cpu for nemo using mpirun: 165 163 \cmd|mpirun -np 62 ./nemo.exe : -np 2 ./xios_server.exe| … … 167 165 \subsubsection{Control of XIOS: the context in iodef.xml} 168 166 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. 167 As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. 171 168 See the XML basics section below for more details on XML syntax and rules. 172 169 … … 205 202 \subsubsection{Installation} 206 203 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. 204 As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. 205 See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. 211 206 NEMO 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. 207 The \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. 216 209 217 210 \subsubsection{Add your own outputs} 218 211 219 212 It 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 213 Many standard fields and diagnostics are already prepared ($i.e.$, steps 1 to 3 below have been done) and 221 214 simply need to be activated by including the required output in a file definition in iodef.xml (step 4). 222 215 To add new output variables, all 4 of the following steps must be taken. 223 216 224 217 \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: 233 227 234 228 \begin{xmllines} … … 241 235 \end{xmllines} 242 236 243 Note your definition must be added to the field\_group whose reference grid is consistent with 244 the size of thearray passed to iomput.245 The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids and246 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.237 Note your definition must be added to the field\_group whose reference grid is consistent with the size of 238 the array passed to iomput. 239 The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, 240 reference 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. 248 242 $e.g.$: 249 243 … … 252 246 \end{xmllines} 253 247 254 Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step, 248 Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step, 255 249 add 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) 260 255 261 256 \begin{xmllines} … … 274 269 275 270 XML 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: 271 You use tags to mark the start and end of elements, which are the logical units of information in an XML document. 272 In addition to marking the beginning of an element, XML start tags also provide a place to specify attributes. 273 An attribute specifies a single property for an element, using a name/value pair, for example: 281 274 \xmlcode{<a b="x" c="y" d="z"> ... </a>}. 282 275 See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details. … … 284 277 \subsubsection{Structure of the XML file used in NEMO} 285 278 286 The XML file used in XIOS is structured by 7 families of tags: 279 The XML file used in XIOS is structured by 7 families of tags: 287 280 context, axis, domain, grid, field, file and variable. 288 281 Each tag family has hierarchy of three flavors (except for context): … … 302 295 303 296 Each element may have several attributes. 304 Some attributes are mandatory, other are optional but have a default value and 305 other are completely optional. 297 Some attributes are mandatory, other are optional but have a default value and other are completely optional. 306 298 Id is a special attribute used to identify an element or a group of elements. 307 299 It must be unique for a kind of element. 308 300 It is optional, but no reference to the corresponding element can be done if it is not defined. 309 301 310 The XML file is split into context tags that are used to isolate IO definition from different codes or311 different parts of a code.302 The XML file is split into context tags that are used to isolate IO definition from 303 different codes or different parts of a code. 312 304 No interference is possible between 2 different contexts. 313 305 Each context has its own calendar and an associated timestep. … … 370 362 371 363 \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 thatare 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 365 are included in the main iodef.xml file through the following commands: 374 366 \begin{xmllines} 375 367 <field_definition src="./field_def.xml" /> … … 380 372 381 373 XML 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. \\ \\ 374 XML has a tree based structure with a parent-child oriented relation: all children inherit attributes from parent, 375 but an attribute defined in a child replace the inherited attribute value. 376 Note that the special attribute ''id'' is never inherited. 377 \\ 378 \\ 386 379 example 1: Direct inheritance. 387 380 … … 393 386 \end{xmllines} 394 387 395 The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average'' 396 ofthe attribute ''operation'' from its parent.388 The field ''sst'' which is part (or a child) of the field\_definition will inherit the value ''average'' of 389 the attribute ''operation'' from its parent. 397 390 Note 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. \\ \\ 391 In the example above, the field ''sss'' will for example output instantaneous values instead of average values. 392 \\ 393 \\ 400 394 example 2: Inheritance by reference. 401 395 … … 418 412 419 413 Groups can be used for 2 purposes. 420 Firstly, the group can be used to define common attributes to be shared by the elements of 414 Firstly, the group can be used to define common attributes to be shared by the elements of 421 415 the group through inheritance. 422 416 In 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''. 417 Note that for the field ''toce'', we overwrite the grid definition inherited from the group by ''grid\_T\_3D''. 425 418 426 419 \begin{xmllines} … … 456 449 \subsection{Detailed functionalities} 457 450 458 The file \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml} provides several examples of the use of 451 The file \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml} provides several examples of the use of 459 452 the new functionalities offered by the XML interface of XIOS. 460 453 461 454 \subsubsection{Define horizontal subdomains} 462 455 463 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of 456 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of 464 457 the tag family domain. 465 458 It must therefore be done in the domain part of the XML file. … … 472 465 \end{xmllines} 473 466 474 The use of this subdomain is done through the redefinition of the attribute domain\_ref of 475 the tag family field. 467 The use of this subdomain is done through the redefinition of the attribute domain\_ref of the tag family field. 476 468 For example: 477 469 … … 483 475 484 476 Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 485 The Equatorial section, the TAO, RAMA and PIRATA moorings are alre dy registered in the code and477 The Equatorial section, the TAO, RAMA and PIRATA moorings are already registered in the code and 486 478 can therefore be outputted without taking care of their (i,j) position in the grid. 487 479 These 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 for489 TAO, RAMA and PIRATA followed by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...)480 ''EqT'', ''EqU'' or ''EqW'' for the equatorial sections and 481 the mooring position for TAO, RAMA and PIRATA followed by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...) 490 482 491 483 \begin{xmllines} … … 503 495 \subsubsection{Define vertical zooms} 504 496 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. 497 Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis. 498 It must therefore be done in the axis part of the XML file. 507 499 For example, in \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml}, we provide the following example: 508 500 … … 513 505 \end{xmllines} 514 506 515 The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of 516 the tag family field. 507 The use of this vertical zoom is done through the redefinition of the attribute axis\_ref of the tag family field. 517 508 For example: 518 509 … … 539 530 \end{xmllines} 540 531 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 532 However it is often very convienent to define the file name with the name of the experiment, 533 the output file frequency and the date of the beginning and the end of the simulation 543 534 (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 on545 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:535 To do so, we added the following rule: 536 if the id of the tag file is ''fileN'' (where N = 1 to 999 on 1 to 3 digits) or 537 one of the predefined sections or moorings (see next subsection), 538 the following part of the name and the name\_suffix (that can be inherited) will be automatically replaced by: 548 539 549 540 \begin{table} \scriptsize … … 580 571 \end{forlines} 581 572 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} 584 574 585 575 \subsubsection{Other controls of the XML attributes from NEMO} 586 576 587 577 The 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}). 579 Any definition given in the XML file will be overwritten. 580 By 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 584 Here is the list of these attributes: 585 \\ 594 586 595 587 \begin{table} \scriptsize … … 631 623 632 624 \begin{enumerate} 633 \item Simple computation: directly define the computation when refering to the variable in634 the file definition.625 \item 626 Simple computation: directly define the computation when refering to the variable in the file definition. 635 627 636 628 \begin{xmllines} … … 640 632 \end{xmllines} 641 633 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. 643 636 644 637 in field\_definition: … … 654 647 \end{xmllines} 655 648 656 Note that in this case, the following syntaxe \xmlcode{<field field_ref="sst2" />} is not working as 649 Note that in this case, the following syntaxe \xmlcode{<field field_ref="sst2" />} is not working as 657 650 sst2 won't be evaluated. 658 651 659 \item Change of variable precision: 652 \item 653 Change of variable precision: 660 654 661 655 \begin{xmllines} … … 667 661 668 662 Note 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: 663 real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. 664 Forcing double precision outputs with prec="8" (for example in the field\_definition) will avoid this problem. 665 666 \item 667 add user defined attributes: 675 668 676 669 \begin{xmllines} … … 687 680 \end{xmllines} 688 681 689 \item use of the ``@'' function: example 1, weighted temporal average 682 \item 683 use of the ``@'' function: example 1, weighted temporal average 690 684 691 685 - define a new variable in field\_definition … … 706 700 707 701 The 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: 702 The temporal operation done by the ``@'' is the one defined in the field definition: 709 703 here we use the default, average. 710 704 So, 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 705 Operation="instant" refers to the temporal operation to be performed on the field''@toce\_e3t / @e3t'': 706 here the temporal average is alreday done by the ``@'' function so we just use instant to do the ratio of 713 707 the 2 mean values. 714 708 field\_ref="toce" means that attributes not explicitely defined, are inherited from toce field. 715 709 Note that in this case, freq\_op must be equal to the file output\_freq. 716 710 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 718 713 719 714 - define a new variable in field\_definition … … 737 732 738 733 The 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: 734 The temporal operation done by the ``@'' is the one defined in the field definition: 740 735 here we use the default, average. 741 736 So, 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 )'': 737 Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'': 744 738 here the temporal average is alreday done by the ``@'' function so we just use instant. 745 739 field\_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field. 746 740 Note that in this case, freq\_op must be equal to the file output\_freq. 747 741 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 749 744 750 745 - define 2 new variables in field\_definition … … 770 765 771 766 The 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 for773 sstmax and minimum for sstmin.767 The temporal operation done by the ``@'' is the one defined in the field definition: 768 here maximum for sstmax and minimum for sstmin. 774 769 So, 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'': 770 Operation="average" refers to the temporal operation to be performed on the field ``@sstmax - @sstmin'': 776 771 here monthly mean (of daily max - daily min of the sst). 777 772 field\_ref="sst" means that attributes not explicitely defined, are inherited from sst field. … … 1126 1121 1127 1122 Output 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 1124 the CF metadata standard. 1125 Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of 1126 section \autoref{subsec:IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard. 1127 1128 Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by 1129 the namelist parameter \np{ln\_cfmeta} in the \ngn{namrun} namelist. 1136 1130 This must be set to true if these metadata are to be included in the output files. 1137 1131 … … 1144 1138 1145 1139 Since 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 vianamelist settings.1140 These options build on the standard NetCDF output and allow the user control over the size of the chunks via 1141 namelist settings. 1148 1142 Chunking 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 1143 For a fuller discussion on chunking and other performance issues the reader is referred to 1144 the NetCDF4 documentation found \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}. 1145 1146 The 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). 1148 Datasets created with chunking and compression are not backwards compatible with NetCDF3 "classic" format but 1149 most analysis codes can be relinked simply with the new libraries and will then read both NetCDF3 and NetCDF4 files. 1150 NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by 1160 1151 setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} namelist: 1161 1152 … … 1166 1157 1167 1158 If \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 1159 In this case, \np{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined. 1160 These functions will not be used but need to be included so that compilation is possible with NetCDF3 libraries. 1161 1162 When using NetCDF4 libraries, \key{netcdf4} should be defined even if the intention is to 1174 1163 create only NetCDF3-compatible files. 1175 This is necessary to avoid duplication between the dummy routines and 1176 the actual routines present in the library. 1164 This is necessary to avoid duplication between the dummy routines and the actual routines present in the library. 1177 1165 Most 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 1166 Thus when linking with NetCDF4 libraries the user must define \key{netcdf4} and 1179 1167 control the type of NetCDF file produced via the namelist parameter. 1180 1168 1181 Chunking and compression is applied only to 4D fields and there is no advantage in1182 chunking across more than one time dimension since previously written chunks would have to 1183 be read back and decompressed before being added to.1169 Chunking and compression is applied only to 4D fields and 1170 there is no advantage in chunking across more than one time dimension since 1171 previously written chunks would have to be read back and decompressed before being added to. 1184 1172 Therefore, user control over chunk sizes is provided only for the three space dimensions. 1185 1173 The 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 1174 The actual size of the chunks will depend on global domain size for mono-processors or, more likely, 1175 the local processor domain size for distributed processing. 1176 The derived values are subject to practical minimum values (to avoid wastefully small chunk sizes) and 1189 1177 cannot be greater than the domain size in any dimension. 1190 1178 The algorithm used is: … … 1203 1191 \end{forlines} 1204 1192 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 1206 1194 the mono-processor case (i.e. global domain of {\small\tt 182x149x31}). 1207 1195 An 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 witha 4x2 mpi partitioning.1210 Note the variation in the compression ratio achieved which reflects chiefly the dry to 1211 wet volume ratio ofeach processing region.1196 table \autoref{tab:NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with 1197 a 4x2 mpi partitioning. 1198 Note the variation in the compression ratio achieved which reflects chiefly the dry to wet volume ratio of 1199 each processing region. 1212 1200 1213 1201 %------------------------------------------TABLE---------------------------------------------------- … … 1249 1237 %---------------------------------------------------------------------------------------------------- 1250 1238 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 toserve 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 1239 When \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}. 1242 Typically this namelist serves the mean files whilst the \ngn{ namnc4} in the main namelist file continues to 1243 serve the restart files. 1244 This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of 1245 the individual files produced by the io\_server processes may be different to those produced by 1258 1246 the invidual processing regions and different chunking choices may be desired. 1259 1247 … … 1269 1257 %------------------------------------------------------------------------------------------------------------- 1270 1258 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.$ at1273 the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines).1259 Each 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). 1274 1262 This capability is controlled by options offered in \ngn{namtrd} namelist. 1275 1263 Note that the output are done with xIOS, and therefore the \key{IOM} is required. … … 1278 1266 1279 1267 \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; 1294 1286 \end{description} 1295 1287 … … 1298 1290 1299 1291 \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).1292 In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are not working, 1293 and none of the options have been tested with variable volume ($i.e.$ \key{vvl} defined). 1302 1294 1303 1295 % ------------------------------------------------------------------------------------------------------------- … … 1311 1303 %-------------------------------------------------------------------------------------------------------------- 1312 1304 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. 1305 The on-line computation of floats advected either by the three dimensional velocity field or constraint to 1306 remain at a given depth ($w = 0$ in the computation) have been introduced in the system during the CLIPPER project. 1316 1307 Options are defined by \ngn{namflo} namelis variables. 1317 The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option), or1318 o n 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 1308 The algorithm used is based either on the work of \cite{Blanke_Raynaud_JPO97} (default option), 1309 or on a $4^th$ Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}). 1310 Note that the \cite{Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which 1320 1311 are consistent with the numeric of the code, so that the trajectories never intercept the bathymetry. 1321 1312 1322 1313 \subsubsection{Input data: initial coordinates} 1323 1314 1324 Initial coordinates can be given with Ariane Tools convention (IJK coordinates,1325 ( \np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude.1315 Initial coordinates can be given with Ariane Tools convention 1316 (IJK coordinates, (\np{ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude. 1326 1317 1327 1318 In case of Ariane convention, input filename is \np{init\_float\_ariane}. … … 1368 1359 1369 1360 \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.} ), 1361 When initial positions are read in a restart file (\np{ln\_rstflo}\forcode{ = .true.} ), 1371 1362 \np{jpnflnewflo} can be added in the initialization file. 1372 1363 1373 1364 \subsubsection{Output data} 1374 1365 1375 \np{nn\_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} is 1376 the frequency ofcreation 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 1367 creation of the float restart file. 1377 1368 1378 1369 Output data can be written in ascii files (\np{ln\_flo\_ascii}\forcode{ = .true.}). … … 1382 1373 There are 2 possibilities: 1383 1374 1384 1385 1375 - if (\key{iomput}) is used, outputs are selected in iodef.xml. 1376 Here it is an example of specification to put in files description section: 1386 1377 1387 1378 \begin{xmllines} … … 1401 1392 - if (\key{iomput}) is not used, a file called \ifile{trajec\_float} will be created by IOIPSL library. 1402 1393 1403 See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing 1404 the off-line use ofthis 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. 1405 1396 1406 1397 % ------------------------------------------------------------------------------------------------------------- … … 1418 1409 This on-line Harmonic analysis is actived with \key{diaharm}. 1419 1410 1420 Some parameters are available in namelist \ngn{namdia\_harm} 1411 Some parameters are available in namelist \ngn{namdia\_harm}: 1421 1412 1422 1413 - \np{nit000\_han} is the first time step used for harmonic analysis … … 1430 1421 - \np{tname} is an array with names of tidal constituents to analyse 1431 1422 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: 1436 1427 1437 1428 \[h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[A_{j}cos(\nu_{j}t_{j}-\phi_{j})] = e_{i}\] 1438 1429 1439 With $A_{j}$, $\nu_{j}$, $\phi_{j}$, the amplitude, frequency and phase for each wave and 1440 $e_{i}$ the error. 1430 With $A_{j}$, $\nu_{j}$, $\phi_{j}$, the amplitude, frequency and phase for each wave and $e_{i}$ the error. 1441 1431 $h_{i}$ is the sea level for the time $t_{i}$ and $A_{0}$ is the mean sea level. \\ 1442 1432 We can rewrite this equation: … … 1459 1449 %------------------------------------------------------------------------------------------------------------- 1460 1450 1461 A module is available to compute the transport of volume, heat and salt through sections. 1451 A module is available to compute the transport of volume, heat and salt through sections. 1462 1452 This diagnostic is actived with \key{diadct}. 1463 1453 1464 1454 Each 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. 1455 The pathways between them are contructed using tools which can be found in \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT} 1456 and are written in a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by 1457 NEMO to compute on-line transports. 1470 1458 1471 1459 The on-line transports module creates three output ascii files: … … 1477 1465 - \texttt{salt\_transport} for salt transports (unit: $10^{9}Kg s^{-1}$) \\ 1478 1466 1479 Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over 1480 whichthey are averaged, as well as the level of output for debugging:1467 Namelist variables in \ngn{namdct} control how frequently the flows are summed and the time scales over which 1468 they are averaged, as well as the level of output for debugging: 1481 1469 \np{nn\_dct} : frequency of instantaneous transports computing 1482 1470 \np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports ) … … 1485 1473 \subsubsection{Creating a binary file containing the pathway of each section} 1486 1474 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).1475 In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run}, 1476 the 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). 1490 1478 1491 1479 Another file is available for the GYRE configuration (\texttt{ {list\_sections.ascii\_GYRE}}). … … 1505 1493 - \texttt{ice} to compute surface and volume ice transports, \texttt{noice} if no. \\ 1506 1494 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: \\ 1511 1499 {\scriptsize \texttt{ 1512 1500 long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name \\ … … 1531 1519 - \texttt{zsigp} for potential density classes \\ 1532 1520 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: \\ 1541 1529 \noindent {\scriptsize \texttt{ 1542 1530 -68. -54.5 -60. -64.7 00 okstrpond noice ACC\_Drake\_Passage \\ … … 1559 1547 transport\_total}} \\ 1560 1548 1561 For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for 1562 each class andthe 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 1549 For sections with classes, the first \texttt{nclass-1} lines correspond to the transport for each class and 1550 the last line corresponds to the total transport summed over all classes. 1551 For sections with no classes, class number \texttt{1} corresponds to \texttt{total class} and 1564 1552 this class is called \texttt{N}, meaning \texttt{none}. 1565 1553 … … 1568 1556 - \texttt{transport\_direction2} is the negative part of the transport ($\leq$ 0). \\ 1569 1557 1570 \noindent The \texttt{section slope coefficient} gives information about the significance of 1571 transports signs anddirection: \\1558 \noindent The \texttt{section slope coefficient} gives information about the significance of transports signs and 1559 direction: \\ 1572 1560 1573 1561 \begin{table} \scriptsize … … 1591 1579 1592 1580 1593 Changes in steric sea level are caused when changes in the density of the water column imply an 1594 expansion orcontraction of the column.1595 It is essentially produced through surface heating/cooling and to a lesser extent through 1596 non-linear effects ofthe equation of state (cabbeling, thermobaricity...).1581 Changes in steric sea level are caused when changes in the density of the water column imply an expansion or 1582 contraction of the column. 1583 It is essentially produced through surface heating/cooling and to a lesser extent through non-linear effects of 1584 the equation of state (cabbeling, thermobaricity...). 1597 1585 Non-Boussinesq models contain all ocean effects within the ocean acting on the sea level. 1598 1586 In particular, they include the steric effect. 1599 In contrast, Boussinesq models, such as \NEMO, conserve volume, rather than mass, 1587 In contrast, Boussinesq models, such as \NEMO, conserve volume, rather than mass, 1600 1588 and so do not properly represent expansion or contraction. 1601 1589 The 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 1590 This 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, 1592 as steric changes are an important contribution to local changes in sea level on seasonal and climatic time scales. 1593 This is especially true for investigation into sea level rise due to global warming. 1594 1595 Fortunately, the steric contribution to the sea level consists of a spatially uniform component that 1609 1596 can 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.1597 In order to better understand how global mean sea level evolves and thus how the steric sea level can be diagnosed, 1598 we compare, in the following, the non-Boussinesq and Boussinesq cases. 1612 1599 1613 1600 Let denote … … 1628 1615 \] 1629 1616 1630 Temporal changes in total mass is obtained from the density conservation equation 1617 Temporal changes in total mass is obtained from the density conservation equation: 1631 1618 1632 1619 \[ \frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} ) … … 1634 1621 \label{eq:Co_nBq} \] 1635 1622 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). 1623 where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass exchanges with the other media of 1624 the Earth system (atmosphere, sea-ice, land). 1638 1625 Its global averaged leads to the total mass change 1639 1626 … … 1642 1629 1643 1630 where $\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 1631 Bringing \autoref{eq:Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to 1645 1632 the evolution equation of the mean sea level 1646 1633 … … 1649 1636 \label{eq:ssh_nBq} \] 1650 1637 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: 1638 The first term in equation \autoref{eq:ssh_nBq} alters sea level by adding or subtracting mass from the ocean. 1639 The second term arises from temporal changes in the global mean density; $i.e.$ from steric effects. 1640 1641 In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ appears multiplied by 1642 the gravity ($i.e.$ in the hydrostatic balance of the primitive Equations). 1643 In particular, the mass conservation equation, \autoref{eq:Co_nBq}, degenerates into the incompressibility equation: 1659 1644 1660 1645 \[ \frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) … … 1667 1652 \label{eq:V_Bq} \] 1668 1653 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 1654 Only 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}$. 1656 The total volume (or equivalently the global mean sea level) is altered only by net volume fluxes across 1657 the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid. 1658 1659 Nevertheless, following \citep{Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by 1676 1660 considering 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,1661 The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface mass flux 1662 must be compensated by a spatially uniform change in the mean sea level due to expansion/contraction of the ocean 1663 \citep{Greatbatch_JGR94}. 1664 In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$, 1665 the total mass of the ocean seen by the Boussinesq model, via the steric contribution to the sea level, 1682 1666 $\eta_s$, a spatially uniform variable, as follows: 1683 1667 … … 1685 1669 \label{eq:M_Bq} \] 1686 1670 1687 Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through 1688 the ocean surfaceis converted into a mean change in sea level.1689 Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$, where1690 $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:1671 Any change in $\mathcal{M}$ which cannot be explained by the net mass flux through the ocean surface 1672 is converted into a mean change in sea level. 1673 Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$, 1674 where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos}) 1675 in \autoref{eq:M_Bq} leads to a very simple form for the steric height: 1692 1676 1693 1677 \[ \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D} … … 1699 1683 We do not recommend that. 1700 1684 Indeed, 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 in1702 the pressure gradient term of the momentum equation) it is definitively not a good idea when 1703 i nter-comparing experiments.1685 Since $\rho_o$ has a direct effect on the dynamics of the ocean 1686 (it appears in the pressure gradient term of the momentum equation) 1687 it is definitively not a good idea when inter-comparing experiments. 1704 1688 We 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 than2$\%$ from this value (\cite{Gill1982}, page 47).1708 1709 Second, we have assumed here that the total ocean surface, $\mathcal{A}$, does not change when1710 the sea level is changing as it is the case in all global ocean GCMs 1689 This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since, 1690 with the exception of only a small percentage of the ocean, density in the World Ocean varies by no more than 1691 2$\%$ from this value (\cite{Gill1982}, page 47). 1692 1693 Second, we have assumed here that the total ocean surface, $\mathcal{A}$, 1694 does not change when the sea level is changing as it is the case in all global ocean GCMs 1711 1695 (wetting and drying of grid point is not allowed). 1712 1696 1713 Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of 1714 free surface which is considered. 1697 Third, the discretisation of \autoref{eq:steric_Bq} depends on the type of free surface which is considered. 1715 1698 In the non linear free surface case, $i.e.$ \key{vvl} defined, it is given by 1716 1699 … … 1719 1702 \label{eq:discrete_steric_Bq_nfs} \] 1720 1703 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: 1704 whereas in the linear free surface, 1705 the volume above the \textit{z=0} surface must be explicitly taken into account to 1706 better approximate the total ocean mass and thus the steric sea level: 1723 1707 1724 1708 \[ \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 } … … 1729 1713 In the real ocean, sea ice (and snow above it) depresses the liquid seawater through its mass loading. 1730 1714 This 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, 1715 There is, however, no dynamical effect associated with these depressions in the liquid ocean sea level, 1732 1716 so 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. 1717 Hence, 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}. 1719 However, in the current version of \NEMO the sea-ice is levitating above the ocean without mass exchanges between 1720 ice and ocean. 1721 Therefore the model effective sea level is always given by $\eta + \eta_s$, whether or not there is sea ice present. 1739 1722 1740 1723 In AR5 outputs, the thermosteric sea level is demanded. … … 1747 1730 where $S_o$ and $p_o$ are the initial salinity and pressure, respectively. 1748 1731 1749 Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs 1750 the \key{diaar5} defined tobe called.1732 Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs the \key{diaar5} defined to 1733 be called. 1751 1734 1752 1735 % ------------------------------------------------------------------------------------------------------------- … … 1761 1744 \subsection{Depth of various quantities (\protect\mdl{diahth})} 1762 1745 1763 Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key: 1746 Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key: 1764 1747 1765 1748 - the mixed layer depth (based on a density criterion \citep{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth}) … … 1782 1765 %----------------------------------------------------------------------------------------- 1783 1766 1784 The poleward heat and salt transports, their advective and diffusive component, and1785 the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true 1767 The poleward heat and salt transports, their advective and diffusive component, 1768 and the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true 1786 1769 (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}). 1770 When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic, Indian, 1771 Pacific and Indo-Pacific Oceans (defined north of 30\deg S) as well as for the World Ocean. 1772 The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains three 2D mask arrays, 1773 the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:mask_subasins}). 1792 1774 1793 1775 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 and1802 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.} 1803 1785 \end{center} \end{figure} 1804 1786 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> … … 1827 1809 The 25 hour mean is available for daily runs by summing up the 25 hourly instantananeous hourly values from 1828 1810 midnight at the start of the day to midight at the day end. 1829 This diagnostic is actived with the logical $ln\_dia25h$1811 This diagnostic is actived with the logical $ln\_dia25h$. 1830 1812 1831 1813 % ----------------------------------------------------------- … … 1839 1821 %---------------------------------------------------------------------------------------------------------- 1840 1822 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. 1823 A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables. 1824 This can be a useful diagnostic when hourly or sub-hourly output is required in high resolution tidal outputs. 1845 1825 The tidal signal is retained but the overall data usage is cut to just three vertical levels. 1846 1826 Also the bottom level is calculated for each cell. 1847 This diagnostic is actived with the logical $ln\_diatmb$1827 This diagnostic is actived with the logical $ln\_diatmb$. 1848 1828 1849 1829 % ----------------------------------------------------------- … … 1859 1839 1860 1840 in 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 fromthe continuity equation rather than as a prognostic variable.1841 The vertical component is included although it is not strictly valid as the vertical velocity is calculated from 1842 the continuity equation rather than as a prognostic variable. 1863 1843 Physically 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. 1844 Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step. 1845 1846 The variables can be activated by setting the \np{nn\_diacfl} namelist parameter to 1 in the \ngn{namctl} namelist. 1869 1847 The 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 ofwhere 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 alongwith the coordinates of each.1848 In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with the coordinates of 1849 where the maximum value occurs. 1850 At the end of the model run the maximum value of $C_u$, $C_v$, and $C_w$ for the whole model run is printed along 1851 with the coordinates of each. 1874 1852 The maximum values from the run are also copied to the ocean.output file. 1875 1853
Note: See TracChangeset
for help on using the changeset viewer.