# Changeset 11218 for NEMO/trunk/doc/latex/NEMO/subfiles/chap_DIA.tex

Ignore:
Timestamp:
2019-07-05T11:19:53+02:00 (15 months ago)
Message:

revision of chap_DIA.tex in NEMO doc

File:
1 edited

### Legend:

Unmodified
 r11179 the same run performed in one step. It should be noted that this requires that the restart file contains two consecutive time steps for all the prognostic variables, and that it is saved in the same binary format as the one used by the computer that is to read it (in particular, 32 bits binary IEEE format must not be used for this file). all the prognostic variables. The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs. the writing work is distributed over the processors in massively parallel computing. A complete description of the use of this I/O server is presented in the next section. By default, \key{iomput} is not 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). %\gmcomment{                    % start of gmcomment 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: \path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml}, \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}. \\ Examples of the XML files that control the outputs can be found in: \path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef.xml}, \path{cfgs/SHARED/field_def_nemo-oce.xml}, \path{cfgs/SHARED/field_def_nemo-pisces.xml}, \path{cfgs/SHARED/field_def_nemo-ice.xml} and \path{cfgs/SHARED/domain_def_nemo.xml}. \\ The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). 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} an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-2.5}{XIOS-2.5} (use of revision 618 or higher is required). This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to 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 \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS} {XIOS with NEMO} guide provides an example illustration of how this can be achieved. The \href{https://forge.ipsl.jussieu.fr/nemo/chrome/site/doc/NEMO/guide/html/install.html#extract-and-install-xios} {Extract and install XIOS} guide provides an example illustration of how this can be achieved. \subsubsection{Add your own outputs} \begin{enumerate} \item[1.] in NEMO code, add a \forcode{CALL iom\_put( 'identifier', array )} where you want to output a 2D or 3D array. in NEMO code, add a \forcode{CALL iom_put( 'identifier', array )} where you want to output a 2D or 3D array. \item[2.] If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in \xmlline|| \noindent In NEMO, by default, the field and domain definition is done in 2 separate files: \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml} that \noindent In NEMO, by default, the field definition is done in 3 separate files ( \path{cfgs/SHARED/field_def_nemo-oce.xml}, \path{cfgs/SHARED/field_def_nemo-pisces.xml} and \path{cfgs/SHARED/field_def_nemo-ice.xml} ) and the  domain definition is done in another file ( \path{cfgs/SHARED/domain_def_nemo.xml} ) that are included in the main iodef.xml file through the following commands: \begin{xmllines} \end{xmllines} 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 \path{CONFIG/SHARED/field_def.xml}. Several examples of groups of fields are proposed at the end of the XML field files ( \path{cfgs/SHARED/field_def_nemo-oce.xml}, \path{cfgs/SHARED/field_def_nemo-pisces.xml} and \path{cfgs/SHARED/field_def_nemo-ice.xml} ) . For example, a short list of the usual variables related to the U grid: the tag family domain. It must therefore be done in the domain part of the XML file. For example, in \path{CONFIG/SHARED/domain_def.xml}, we provide the following example of a definition of For example, in \path{cfgs/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). \begin{xmllines} \end{xmllines} \begin{xmllines} \end{xmllines} \subsubsection{Define vertical zooms} Vertical zooms are defined through the attributs zoom\_begin and zoom\_end of the tag family axis. Vertical zooms are defined through the attributs zoom\_begin and zoom\_n of the tag family axis. It must therefore be done in the axis part of the XML file. For example, in \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml}, we provide the following example: \begin{xmllines} For example, in \path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef_demo.xml}, we provide the following example: \begin{xmllines} \end{xmllines} \end{xmllines} Note that, then the code is crashing, writting real4 variables forces a numerical convection from Note that, then the code is crashing, writting real4 variables forces a numerical conversion from real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. Forcing double precision outputs with prec="8" (for example in the field\_definition) will avoid this problem. \subsection{CF metadata standard compliance} Output from the XIOS-1.0 IO server is compliant with Output from the XIOS IO server is compliant with \href{http://cfconventions.org/Data/cf-conventions/cf-conventions-1.5/build/cf-conventions.html}{version 1.5} of the CF metadata standard. Chunking and compression can lead to significant reductions in file sizes for a small runtime overhead. For a fuller discussion on chunking and other performance issues the reader is referred to the NetCDF4 documentation found \href{http://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}. the NetCDF4 documentation found \href{https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_perf_chunking.html}{here}. The new features are only available when the code has been linked with a NetCDF4 library (\ie at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$ routines). This capability is controlled by options offered in \ngn{namtrd} namelist. Note that the output are done with xIOS, and therefore the \key{IOM} is required. Note that the output are done with XIOS, and therefore the \key{iomput} is required. What is done depends on the \ngn{namtrd} logical set to \forcode{.true.}: Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via the \key{trdtrc} and \key{trdmld\_trc} CPP keys. the \key{trdtrc} and \key{trdmxl\_trc} CPP keys. \textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested. The on-line computation of floats advected either by the three dimensional velocity field or constraint to remain at a given depth ($w = 0$ in the computation) have been introduced in the system during the CLIPPER project. Options are defined by \ngn{namflo} namelis variables. Options are defined by \ngn{namflo} namelist variables. The algorithm used is based either on the work of \cite{blanke.raynaud_JPO97} (default option), or on a $4^th$ Runge-Hutta algorithm (\np{ln\_flork4}\forcode{ = .true.}). In case of Ariane convention, input filename is \np{init\_float\_ariane}. Its format is: \\ {\scriptsize \texttt{I J K nisobfl itrash itrash}} {\scriptsize \texttt{I J K nisobfl itrash}} \noindent with: In that case, output filename is trajec\_float. Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii}\forcode{ = .false.}). There are 2 possibilities: - if (\key{iomput}) is used, outputs are selected in  iodef.xml. Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii}\forcode{ = .false.}) with \key{iomput} and outputs selected in iodef.xml. Here it is an example of specification to put in files description section: \end{xmllines} -  if (\key{iomput}) is not used, a file called \ifile{trajec\_float} will be created by IOIPSL library. See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing the off-line use of this marvellous diagnostic tool. % ------------------------------------------------------------------------------------------------------------- \label{sec:DIA_diag_harm} %------------------------------------------namdia_harm---------------------------------------------------- %------------------------------------------nam_diaharm---------------------------------------------------- % \nlst{nam_diaharm} This on-line Harmonic analysis is actived with \key{diaharm}. Some parameters are available in namelist \ngn{namdia\_harm}: Some parameters are available in namelist \ngn{nam\_diaharm}: - \np{nit000\_han} is the first time step used for harmonic analysis Each section is defined by the coordinates of its 2 extremities. The pathways between them are contructed using tools which can be found in \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT} and are written in a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is later read in by The pathways between them are contructed using tools which can be found in \texttt{tools/SECTIONS\_DIADCT} and are written in a binary file \texttt{section\_ijglobal.diadct} which is later read in by NEMO to compute on-line transports. \subsubsection{Creating a binary file containing the pathway of each section} In \texttt{NEMOGCM/TOOLS/SECTIONS\_DIADCT/run}, In \texttt{tools/SECTIONS\_DIADCT/run}, the file \textit{ {list\_sections.ascii\_global}} contains a list of all the sections that are to be computed (this list of sections is based on MERSEA project metrics). The script \texttt{job.ksh} computes the pathway for each section and creates a binary file \texttt{section\_ijglobal.diadct\_ORCA2\_LIM} which is read by NEMO. \\ \texttt{section\_ijglobal.diadct} which is read by NEMO. \\ It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated with