Changeset 6289 for trunk/DOC/TexFiles/Chapters/Chap_DIA.tex
- Timestamp:
- 2016-02-05T00:47:05+01:00 (8 years ago)
- File:
-
- 1 edited
-
trunk/DOC/TexFiles/Chapters/Chap_DIA.tex (modified) (27 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/DOC/TexFiles/Chapters/Chap_DIA.tex
r6140 r6289 12 12 % Old Model Output 13 13 % ================================================================ 14 \section{Old Model Output (default or \key{dimgout})}14 \section{Old Model Output (default)} 15 15 \label{DIA_io_old} 16 16 … … 33 33 "\textit{grep -i numout}" in the source code directory. 34 34 35 By default, diagnostic output files are written in NetCDF format but an IEEE binary output format, called DIMG, can be chosen by defining \key{dimgout}. 36 37 Since version 3.2, when defining \key{iomput}, an I/O server has been added which provides more flexibility in the choice of the fields to be written as well as how the writing work is distributed over the processors in massively parallel computing. The complete description of the use of this I/O server is presented in the next section. 38 39 By default, if neither \key{iomput} nor \key{dimgout} are defined, NEMO produces NetCDF with the old IOIPSL library which has been kept for compatibility and its easy installation. However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2, many diagnostic options have been added presuming the use of \key{iomput}. The usefulness of the default IOIPSL-based option is expected to reduce with each new release. If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module and contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of nn\_write time-steps (namelist parameter). 35 By default, diagnostic output files are written in NetCDF format. 36 Since version 3.2, when defining \key{iomput}, an I/O server has been added 37 which provides more flexibility in the choice of the fields to be written 38 as well as how the writing work is distributed over the processors in massively parallel computing. 39 A complete description of the use of this I/O server is presented in the next section. 40 41 By default, \key{iomput} is not defined, NEMO produces NetCDF with the old IOIPSL library 42 which has been kept for compatibility and its easy installation. 43 However, the IOIPSL library is quite inefficient on parallel machines and, since version 3.2, 44 many diagnostic options have been added presuming the use of \key{iomput}. 45 The usefulness of the default IOIPSL-based option is expected to reduce with each new release. 46 If \key{iomput} is not defined, output files and content are defined in the \mdl{diawri} module 47 and contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period 48 of nn\_write time-steps (namelist parameter). 40 49 41 50 %\gmcomment{ % start of gmcomment … … 48 57 49 58 50 Since version 3.2, iomput is the NEMO output interface of choice. It has been designed to be simple to use, flexible and efficient. The two main purposes of iomput are: 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. 61 The two main purposes of iomput are: 51 62 \begin{enumerate} 52 \item The complete and flexible control of the output files through external XML files adapted by the user from standard templates. 53 \item To achieve high performance and scalable output through the optional distribution of all diagnostic output related tasks to dedicated processes. 63 \item The complete and flexible control of the output files through external XML files 64 adapted by the user from standard templates. 65 \item To achieve high performance and scalable output through the optional distribution 66 of all diagnostic output related tasks to dedicated processes. 54 67 \end{enumerate} 55 The first functionality allows the user to specify, without code changes or recompilation, aspects of the diagnostic output stream, such as: 68 The first functionality allows the user to specify, without code changes or recompilation, 69 aspects of the diagnostic output stream, such as: 56 70 \begin{itemize} 57 71 \item The choice of output frequencies that can be different for each file (including real months and years). 58 \item The choice of file contents; includes complete flexibility over which data are written in which files (the same data can be written in different files). 72 \item The choice of file contents; includes complete flexibility over which data are written in which files 73 (the same data can be written in different files). 59 74 \item The possibility to split output files at a chosen frequency. 60 75 \item The possibility to extract a vertical or an horizontal subdomain. … … 62 77 \item Control over metadata via a large XML "database" of possible output fields. 63 78 \end{itemize} 64 In addition, iomput allows the user to add the output of any new variable (scalar, 2D or 3D) in the code in a very easy way. All details of iomput functionalities are listed in the following subsections. Examples of the XML files that control the outputs can be found in: 79 In addition, iomput allows the user to add in the code the output of any new variable (scalar, 2D or 3D) 80 in a very easy way. All details of iomput functionalities are listed in the following subsections. 81 Examples of the XML files that control the outputs can be found in: 65 82 \begin{alltt} 66 83 \begin{verbatim} … … 72 89 \end{alltt} 73 90 74 The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) to collect and write the outputs. With an appropriate choice of N by the user, the bottleneck associated with the writing of the output files can be greatly reduced. 75 76 In version 3.6, the iom\_put interface depends on an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0} (use of revision 618 or higher is required). This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to create a single output file and therefore to bypass the rebuilding phase. Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to an HDF5 library that has been correctly compiled (i.e. with the configure option $--$enable-parallel). Note that the files created by iomput through XIOS are incompatible with NetCDF3. All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 77 78 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, where N is typically much less than the number of NEMO processors, will reduce the number of output files created. This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. Note that for smaller configurations, the rebuilding phase can be avoided, even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 91 The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). 92 Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMO processes) 93 to collect and write the outputs. With an appropriate choice of N by the user, 94 the bottleneck associated with the writing of the output files can be greatly reduced. 95 96 In version 3.6, the iom\_put interface depends on an external code called 97 \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-1.0}{XIOS-1.0} 98 (use of revision 618 or higher is required). This new IO server can take advantage of 99 the parallel I/O functionality of NetCDF4 to create a single output file and therefore 100 to bypass the rebuilding phase. Note that writing in parallel into the same NetCDF files 101 requires that your NetCDF4 library is linked to an HDF5 library that has been correctly compiled 102 ($i.e.$ with the configure option $--$enable-parallel). 103 Note that the files created by iomput through XIOS are incompatible with NetCDF3. 104 All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 105 106 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, 107 where N is typically much less than the number of NEMO processors, will reduce the number of output files created. 108 This can greatly reduce the post-processing burden usually associated with using large numbers of NEMO processors. 109 Note that for smaller configurations, the rebuilding phase can be avoided, 110 even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 79 111 80 112 \subsection{XIOS: the IO\_SERVER} … … 82 114 \subsubsection{Attached or detached mode?} 83 115 84 Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, the io\_server developed by Yann Meurdesoif from IPSL. The behaviour of the io subsystem is controlled by settings in the external XML files listed above. Key settings in the iodef.xml file are {\tt using\_server} and the {\tt type} tag associated with each defined file. The {\tt using\_server} setting determines whether or not the server will be used in ''attached mode'' (as a library) [{\tt false}] or in ''detached mode'' (as an external executable on N additional, dedicated cpus) [{\tt true}]. The ''attached mode'' is simpler to use but much less efficient for massively parallel applications. The type of each file can be either ''multiple\_file'' or ''one\_file''. 85 86 In attached mode and if the type of file is ''multiple\_file'', then each NEMO process will also act as an IO server and produce its own set of output files. Superficially, this emulates the standard behaviour in previous versions, However, the subdomain written out by each process does not correspond to the {\tt jpi x jpj x jpk} domain actually computed by the process (although it may if {\tt jpni=1}). Instead each process will have collected and written out a number of complete longitudinal strips. If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips and write (in parallel) to a single output file. 87 88 In detached mode and if the type of file is ''multiple\_file'', then each stand-alone XIOS process will collect data for a range of complete longitudinal strips and write to its own set of output files. If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and write (in parallel) to a single output file. Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. The following subsection provides a typical example but the syntax will vary in different MPP environments. 116 Iomput is based on \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS}, 117 the io\_server developed by Yann Meurdesoif from IPSL. 118 The behaviour of the I/O subsystem is controlled by settings in the external XML files listed above. 119 Key settings in the iodef.xml file are {\tt using\_server} and the {\tt type} tag associated with each defined file. 120 The {\tt using\_server} setting determines whether or not the server will be used in \textit{attached mode} (as a library) 121 [{\tt false}] or in \textit{detached mode} (as an external executable on N additional, dedicated cpus) [{\tt true}]. 122 The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications. 123 The type of each file can be either ''multiple\_file'' or ''one\_file''. 124 125 In \textit{attached mode} and if the type of file is ''multiple\_file'', 126 then each NEMO process will also act as an IO server and produce its own set of output files. 127 Superficially, this emulates the standard behaviour in previous versions. 128 However, the subdomain written out by each process does not correspond to the {\tt jpi x jpj x jpk} 129 domain actually computed by the process (although it may if {\tt jpni=1}). 130 Instead each process will have collected and written out a number of complete longitudinal strips. 131 If the ''one\_file'' option is chosen then all processes will collect their longitudinal strips 132 and write (in parallel) to a single output file. 133 134 In \textit{detached mode} and if the type of file is ''multiple\_file'', 135 then each stand-alone XIOS process will collect data for a range of complete longitudinal strips 136 and write to its own set of output files. If the ''one\_file'' option is chosen then 137 all XIOS processes will collect their longitudinal strips and write (in parallel) to a single output file. 138 Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. 139 The following subsection provides a typical example but the syntax will vary in different MPP environments. 89 140 90 141 \subsubsection{Number of cpu used by XIOS in detached mode} 91 142 92 The number of cores used by the XIOS is specified when launching the model. The number of cores dedicated to XIOS should be from ~1/10 to ~1/50 of the number or cores dedicated to NEMO. Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but this is a general recommendation and not specific to NEMO. It is difficult to provide precise recommendations because the optimal choice will depend on the particular hardware properties of the target system (parallel filesystem performance, available memory, memory bandwidth etc.) and the volume and frequency of data to be created. Here is an example of 2 cpus for the io\_server and 62 cpu for nemo using mpirun: 143 The number of cores used by the XIOS is specified when launching the model. 144 The number of cores dedicated to XIOS should be from ~1/10 to ~1/50 of the number or cores dedicated to NEMO. 145 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors 146 but this is a general recommendation and not specific to NEMO. 147 It is difficult to provide precise recommendations because the optimal choice will depend on 148 the particular hardware properties of the target system (parallel filesystem performance, available memory, 149 memory bandwidth etc.) and the volume and frequency of data to be created. 150 Here is an example of 2 cpus for the io\_server and 62 cpu for nemo using mpirun: 93 151 94 152 \texttt{ mpirun -np 62 ./nemo.exe : -np 2 ./xios\_server.exe } … … 96 154 \subsubsection{Control of XIOS: the XIOS context in iodef.xml} 97 155 98 As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. See the XML basics section below for more details on XML syntax and rules. 156 As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. 157 See the XML basics section below for more details on XML syntax and rules. 99 158 100 159 \begin{tabular}{|p{4cm}|p{6.0cm}|p{2.0cm}|} … … 106 165 \hline 107 166 buffer\_size & 108 buffer size used by XIOS to send data from NEMO to XIOS. Larger is more efficient. Note that needed/used buffer sizes are summarized at the end of the job & 167 buffer size used by XIOS to send data from NEMO to XIOS. Larger is more efficient. 168 Note that needed/used buffer sizes are summarized at the end of the job & 109 169 25000000 \\ 110 170 \hline … … 136 196 \subsubsection{Installation} 137 197 138 As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. NEMO will need to link to the compiled XIOS library. The 139 \href{http://www.nemo-ocean.eu/Using-NEMO/User-Guides/Basics/XIOS-IO-server-installation-and-use}{XIOS with NEMO} guide provides an example illustration of how this can be achieved. 198 As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO. 199 See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. 200 NEMO will need to link to the compiled XIOS library. 201 The \href{http://www.nemo-ocean.eu/Using-NEMO/User-Guides/Basics/XIOS-IO-server-installation-and-use}{XIOS with NEMO} 202 guide provides an example illustration of how this can be achieved. 140 203 141 204 \subsubsection{Add your own outputs} 142 205 143 It is very easy to add your own outputs with iomput. Many standard fields and diagnostics are already prepared (i.e., steps 1 to 3 below have been done) and simply need to be activated by including the required output in a file definition in iodef.xml (step 4). To add new output variables, all 4 of the following steps must be taken. 206 It is very easy to add your own outputs with iomput. 207 Many standard fields and diagnostics are already prepared ($i.e.$, steps 1 to 3 below have been done) 208 and simply need to be activated by including the required output in a file definition in iodef.xml (step 4). 209 To add new output variables, all 4 of the following steps must be taken. 144 210 \begin{description} 145 211 \item[1.] in NEMO code, add a \\ … … 151 217 to the list of used modules in the upper part of your module. 152 218 153 \item[3.] in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code (see subsequent sections for a details of the XML syntax and rules). For example: 219 \item[3.] in the field\_def.xml file, add the definition of your variable using the same identifier 220 you used in the f90 code (see subsequent sections for a details of the XML syntax and rules). 221 For example: 154 222 \vspace{-20pt} 155 223 \begin{alltt} {{\scriptsize … … 165 233 \end{verbatim} 166 234 }}\end{alltt} 167 Note your definition must be added to the field\_group whose reference grid is consistent with the size of the array passed to iomput. The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids and axes either defined in the code (iom\_set\_domain\_attr and iom\_set\_axis\_attr in iom.F90) or defined in the domain\_def.xml file. E.g.: 235 Note your definition must be added to the field\_group whose reference grid is consistent 236 with the size of the array passed to iomput. 237 The grid\_ref attribute refers to definitions set in iodef.xml which, in turn, reference grids 238 and axes either defined in the code (iom\_set\_domain\_attr and iom\_set\_axis\_attr in iom.F90) 239 or defined in the domain\_def.xml file. $e.g.$: 168 240 \vspace{-20pt} 169 241 \begin{alltt} {{\scriptsize … … 173 245 }}\end{alltt} 174 246 Note, if your array is computed within the surface module each nn\_fsbc time\_step, 175 add the field definition within the field\_group defined with the id ''SBC'': $<$field\_group id=''SBC''...$>$ which has been defined with the correct frequency of operations (iom\_set\_field\_attr in iom.F90) 247 add the field definition within the field\_group defined with the id ''SBC'': $<$field\_group id=''SBC''...$>$ 248 which has been defined with the correct frequency of operations (iom\_set\_field\_attr in iom.F90) 176 249 177 250 \item[4.] add your field in one of the output files defined in iodef.xml (again see subsequent sections for syntax and rules) \\ … … 201 274 \subsubsection{Structure of the xml file used in NEMO} 202 275 203 The XML file used in XIOS is structured by 7 families of tags: context, axis, domain, grid, field, file and variable. Each tag family has hierarchy of three flavors (except for context): 276 The XML file used in XIOS is structured by 7 families of tags: context, axis, domain, grid, field, file and variable. 277 Each tag family has hierarchy of three flavors (except for context): 204 278 \\ 205 279 \begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|} … … 225 299 \\ 226 300 227 Each element may have several attributes. Some attributes are mandatory, other are optional but have a default value and other are are completely optional. Id is a special attribute used to identify an element or a group of elements. It must be unique for a kind of element. It is optional, but no reference to the corresponding element can be done if it is not defined. 228 229 The XML file is split into context tags that are used to isolate IO definition from different codes or different parts of a code. No interference is possible between 2 different contexts. Each context has its own calendar and an associated timestep. In NEMO, we used the following contexts (that can be defined in any order):\\ 301 Each element may have several attributes. 302 Some attributes are mandatory, other are optional but have a default value and other are are completely optional. 303 Id is a special attribute used to identify an element or a group of elements. 304 It must be unique for a kind of element. 305 It is optional, but no reference to the corresponding element can be done if it is not defined. 306 307 The XML file is split into context tags that are used to isolate IO definition from different codes 308 or different parts of a code. No interference is possible between 2 different contexts. 309 Each context has its own calendar and an associated timestep. 310 In \NEMO, we used the following contexts (that can be defined in any order):\\ 230 311 \\ 231 312 \begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|} … … 271 352 \\ 272 353 273 \noindent Each context tag related to NEMO (mother or child grids) is divided into 5 parts (that can be defined in any order):\\ 354 \noindent Each context tag related to NEMO (mother or child grids) is divided into 5 parts 355 (that can be defined in any order):\\ 274 356 \\ 275 357 \begin{tabular}{|p{3.0cm}|p{4.5cm}|p{4.5cm}|} … … 305 387 \subsubsection{Nesting XML files} 306 388 307 The XML file can be split in different parts to improve its readability and facilitate its use. The inclusion of XML files into the main XML file can be done through the attribute src: \\ 389 The XML file can be split in different parts to improve its readability and facilitate its use. 390 The inclusion of XML files into the main XML file can be done through the attribute src: \\ 308 391 {\scriptsize \verb? <context src="./nemo_def.xml" /> ?}\\ 309 392 … … 323 406 \subsubsection{Use of inheritance} 324 407 325 XML extensively uses the concept of inheritance. XML has a tree based structure with a parent-child oriented relation: all children inherit attributes from parent, but an attribute defined in a child replace the inherited attribute value. Note that the special attribute ''id'' is never inherited. \\ 408 XML extensively uses the concept of inheritance. 409 XML has a tree based structure with a parent-child oriented relation: 410 all children inherit attributes from parent, but an attribute defined in a child replace the inherited attribute value. 411 Note that the special attribute ''id'' is never inherited. \\ 326 412 \\ 327 413 example 1: Direct inheritance. … … 362 448 \subsubsection{Use of Groups} 363 449 364 Groups can be used for 2 purposes. Firstly, the group can be used to define common attributes to be shared by the elements of the group through inheritance. In the following example, we define a group of field that will share a common grid ''grid\_T\_2D''. Note that for the field ''toce'', we overwrite the grid definition inherited from the group by ''grid\_T\_3D''. 450 Groups can be used for 2 purposes. 451 Firstly, the group can be used to define common attributes to be shared by the elements of the group through inheritance. 452 In the following example, we define a group of field that will share a common grid ''grid\_T\_2D''. 453 Note that for the field ''toce'', we overwrite the grid definition inherited from the group by ''grid\_T\_3D''. 365 454 \vspace{-20pt} 366 455 \begin{alltt} {{\scriptsize … … 375 464 }}\end{alltt} 376 465 377 Secondly, the group can be used to replace a list of elements. Several examples of groups of fields are proposed at the end of the file {\tt CONFIG/SHARED/field\_def.xml}. For example, a short list of the usual variables related to the U grid: 466 Secondly, the group can be used to replace a list of elements. 467 Several examples of groups of fields are proposed at the end of the file {\tt CONFIG/SHARED/field\_def.xml}. 468 For example, a short list of the usual variables related to the U grid: 378 469 \vspace{-20pt} 379 470 \begin{alltt} {{\scriptsize … … 399 490 \subsection{Detailed functionalities } 400 491 401 The file {\tt NEMOGCM/CONFIG/ORCA2\_LIM/iodef\_demo.xml} provides several examples of the use of the new functionalities offered by the XML interface of XIOS. 492 The file {\tt NEMOGCM/CONFIG/ORCA2\_LIM/iodef\_demo.xml} provides several examples of the use 493 of the new functionalities offered by the XML interface of XIOS. 402 494 403 495 \subsubsection{Define horizontal subdomains} 404 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of the tag family domain. It must therefore be done in the domain part of the XML file. For example, in {\tt CONFIG/SHARED/domain\_def.xml}, we provide the following example of a definition of a 5 by 5 box with the bottom left corner at point (10,10). 496 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of the tag family domain. 497 It must therefore be done in the domain part of the XML file. 498 For example, in {\tt CONFIG/SHARED/domain\_def.xml}, we provide the following example of a definition 499 of a 5 by 5 box with the bottom left corner at point (10,10). 405 500 \vspace{-20pt} 406 501 \begin{alltt} {{\scriptsize … … 419 514 \end{verbatim} 420 515 }}\end{alltt} 421 Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. The Equatorial section, the TAO, RAMA and PIRATA moorings are alredy registered in the code and can therefore be outputted without taking care of their (i,j) position in the grid. These predefined domains can be activated by the use of specific domain\_ref: ''EqT'', ''EqU'' or ''EqW'' for the equatorial sections and the mooring position for TAO, RAMA and PIRATA followed by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...) 516 Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 517 The Equatorial section, the TAO, RAMA and PIRATA moorings are alredy registered in the code 518 and can therefore be outputted without taking care of their (i,j) position in the grid. 519 These predefined domains can be activated by the use of specific domain\_ref: ''EqT'', ''EqU'' or ''EqW'' 520 for the equatorial sections and the mooring position for TAO, RAMA and PIRATA followed 521 by ''T'' (for example: ''8s137eT'', ''1.5s80.5eT'' ...) 422 522 \vspace{-20pt} 423 523 \begin{alltt} {{\scriptsize … … 1116 1216 % ------------------------------------------------------------------------------------------------------------- 1117 1217 \section[Tracer/Dynamics Trends (TRD)] 1118 {Tracer/Dynamics Trends (\key{trdtra}, \key{trddyn}, \\ 1119 \key{trddvor}, \key{trdmld})} 1218 {Tracer/Dynamics Trends (\ngn{namtrd})} 1120 1219 \label{DIA_trd} 1121 1220 … … 1124 1223 %------------------------------------------------------------------------------------------------------------- 1125 1224 1126 When \key{trddyn} and/or \key{trddyn} CPP variables are defined, each 1127 trend of the dynamics and/or temperature and salinity time evolution equations 1128 is stored in three-dimensional arrays just after their computation ($i.e.$ at the end 1129 of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). Options are defined by 1130 \ngn{namtrd} namelist variables. These trends are then 1131 used in \mdl{trdmod} (see TRD directory) every \textit{nn\_trd } time-steps. 1132 1133 What is done depends on the CPP keys defined: 1225 Each trend of the dynamics and/or temperature and salinity time evolution equations 1226 can be send to \mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation 1227 ($i.e.$ at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). 1228 This capability is controlled by options offered in \ngn{namtrd} namelist. 1229 Note that the output are done with xIOS, and therefore the \key{IOM} is required. 1230 1231 What is done depends on the \ngn{namtrd} logical set to \textit{true}: 1134 1232 \begin{description} 1135 \item[\key{trddyn}, \key{trdtra}] : a check of the basin averaged properties of the momentum 1136 and/or tracer equations is performed ; 1137 \item[\key{trdvor}] : a vertical summation of the moment tendencies is performed, 1138 then the curl is computed to obtain the barotropic vorticity tendencies which are output ; 1139 \item[\key{trdmld}] : output of the tracer tendencies averaged vertically 1140 either over the mixed layer (\np{nn\_ctls}=0), 1141 or over a fixed number of model levels (\np{nn\_ctls}$>$1 provides the number of level), 1142 or over a spatially varying but temporally fixed number of levels (typically the base 1143 of the winter mixed layer) read in \ifile{ctlsurf\_idx} (\np{nn\_ctls}=1) ; 1233 \item[\np{ln\_glo\_trd}] : at each \np{nn\_trd} time-step a check of the basin averaged properties 1234 of the momentum and tracer equations is performed. This also includes a check of $T^2$, $S^2$, 1235 $\tfrac{1}{2} (u^2+v2)$, and potential energy time evolution equations properties ; 1236 \item[\np{ln\_dyn\_trd}] : each 3D trend of the evolution of the two momentum components is output ; 1237 \item[\np{ln\_dyn\_mxl}] : each 3D trend of the evolution of the two momentum components averaged 1238 over the mixed layer is output ; 1239 \item[\np{ln\_vor\_trd}] : a vertical summation of the moment tendencies is performed, 1240 then the curl is computed to obtain the barotropic vorticity tendencies which are output ; 1241 \item[\np{ln\_KE\_trd}] : each 3D trend of the Kinetic Energy equation is output ; 1242 \item[\np{ln\_tra\_trd}] : each 3D trend of the evolution of temperature and salinity is output ; 1243 \item[\np{ln\_tra\_mxl}] : each 2D trend of the evolution of temperature and salinity averaged 1244 over the mixed layer is output ; 1144 1245 \end{description} 1145 1146 The units in the output file can be changed using the \np{nn\_ucf} namelist parameter.1147 For example, in case of salinity tendency the units are given by PSU/s/\np{nn\_ucf}.1148 Setting \np{nn\_ucf}=86400 ($i.e.$ the number of second in a day) provides the tendencies in PSU/d.1149 1150 When \key{trdmld} is defined, two time averaging procedure are proposed.1151 Setting \np{ln\_trdmld\_instant} to \textit{true}, a simple time averaging is performed,1152 so that the resulting tendency is the contribution to the change of a quantity between1153 the two instantaneous values taken at the extremities of the time averaging period.1154 Setting \np{ln\_trdmld\_instant} to \textit{false}, a double time averaging is performed,1155 so that the resulting tendency is the contribution to the change of a quantity between1156 two \textit{time mean} values. The later option requires the use of an extra file, \ifile{restart\_mld}1157 (\np{ln\_trdmld\_restart}=true), to restart a run.1158 1159 1246 1160 1247 Note that the mixed layer tendency diagnostic can also be used on biogeochemical models 1161 1248 via the \key{trdtrc} and \key{trdmld\_trc} CPP keys. 1249 1250 \textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested. 1251 In particular, options associated with \np{ln\_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} 1252 are not working, and none of the option have been tested with variable volume ($i.e.$ \key{vvl} defined). 1253 1162 1254 1163 1255 % ------------------------------------------------------------------------------------------------------------- … … 1280 1372 \label{DIA_diag_harm} 1281 1373 1282 A module is available to compute the amplitude and phase for tidal waves.1283 This diagnostic is actived with \key{diaharm}.1284 1285 1374 %------------------------------------------namdia_harm---------------------------------------------------- 1286 1375 \namdisplay{namdia_harm} 1287 1376 %---------------------------------------------------------------------------------------------------------- 1288 1377 1289 Concerning the on-line Harmonic analysis, some parameters are available in namelist 1290 \ngn{namdia\_harm} : 1291 1292 - \texttt{nit000\_han} is the first time step used for harmonic analysis 1293 1294 - \texttt{nitend\_han} is the last time step used for harmonic analysis 1295 1296 - \texttt{nstep\_han} is the time step frequency for harmonic analysis 1297 1298 - \texttt{nb\_ana} is the number of harmonics to analyse 1299 1300 - \texttt{tname} is an array with names of tidal constituents to analyse 1301 1302 \texttt{nit000\_han} and \texttt{nitend\_han} must be between \texttt{nit000} and \texttt{nitend} of the simulation. 1378 A module is available to compute the amplitude and phase of tidal waves. 1379 This on-line Harmonic analysis is actived with \key{diaharm}. 1380 Some parameters are available in namelist \ngn{namdia\_harm} : 1381 1382 - \np{nit000\_han} is the first time step used for harmonic analysis 1383 1384 - \np{nitend\_han} is the last time step used for harmonic analysis 1385 1386 - \np{nstep\_han} is the time step frequency for harmonic analysis 1387 1388 - \np{nb\_ana} is the number of harmonics to analyse 1389 1390 - \np{tname} is an array with names of tidal constituents to analyse 1391 1392 \np{nit000\_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation. 1303 1393 The restart capability is not implemented. 1304 1394 1305 The Harmonic analysis solve th isequation:1395 The Harmonic analysis solve the following equation: 1306 1396 \begin{equation} 1307 1397 h_{i} - A_{0} + \sum^{nb\_ana}_{j=1}[A_{j}cos(\nu_{j}t_{j}-\phi_{j})] = e_{i} … … 1350 1440 \label{DIA_diag_dct} 1351 1441 1352 A module is available to compute the transport of volume, heat and salt through sections. This diagnostic1353 is actived with \key{diadct}.1442 A module is available to compute the transport of volume, heat and salt through sections. 1443 This diagnostic is actived with \key{diadct}. 1354 1444 1355 1445 Each section is defined by the coordinates of its 2 extremities. The pathways between them are contructed … … 1373 1463 %------------------------------------------------------------------------------------------------------------- 1374 1464 1375 \ texttt{nn\_dct}: frequency of instantaneous transports computing1376 1377 \ texttt{nn\_dctwri}: frequency of writing ( mean of instantaneous transports )1378 1379 \ texttt{nn\_debug}: debugging of the section1465 \np{nn\_dct}: frequency of instantaneous transports computing 1466 1467 \np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports ) 1468 1469 \np{nn\_debug}: debugging of the section 1380 1470 1381 1471 \subsubsection{ To create a binary file containing the pathway of each section } … … 1508 1598 the \key{diahth} CPP key: 1509 1599 1510 - the mixed layer depth (based on a density criterion , \citet{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth})1600 - the mixed layer depth (based on a density criterion \citep{de_Boyer_Montegut_al_JGR04}) (\mdl{diahth}) 1511 1601 1512 1602 - the turbocline depth (based on a turbulent mixing coefficient criterion) (\mdl{diahth})
Note: See TracChangeset
for help on using the changeset viewer.
