Changeset 11830
- Timestamp:
- 2019-10-29T17:51:07+01:00 (4 years ago)
- Location:
- NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc
- Files:
-
- 53 deleted
- 125 edited
- 65 copied
Legend:
- Unmodified
- Added
- Removed
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc
- Property svn:ignore deleted
- Property svn:mergeinfo deleted
-
Property
svn:externals
set to
^/utils/badges badges
^/utils/logos logos
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex
- Property svn:ignore deleted
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/HTML_latex2html.sh
r10146 r11830 1 1 #!/bin/bash 2 2 3 ./inc/clean.sh4 ./inc/build.sh3 #./inc/clean.sh 4 #./inc/build.sh 5 5 6 cd tex_main 7 sed -i -e 's#\\documentclass#%\\documentclass#' -e '/{document}/ s/^/%/' \ 8 ../tex_sub/*.tex 9 sed -i 's#\\subfile{#\\include{#g' \ 10 NEMO_manual.tex 11 latex2html -local_icons -no_footnode -split 4 -link 2 -mkdir -dir ../html_LaTeX2HTML \ 12 $* \ 13 NEMO_manual 14 sed -i -e 's#%\\documentclass#\\documentclass#' -e '/{document}/ s/^%//' \ 15 ../tex_sub/*.tex 16 sed -i 's#\\include{#\\subfile{#g' \ 17 NEMO_manual.tex 6 sed -i -e 's#utf8#latin1#' \ 7 -e 's#\[outputdir=../build\]{minted}#\[\]{minted}#' \ 8 -e '/graphicspath/ s#{../#{../../#g' \ 9 global/packages.tex 10 11 cd ./NEMO/main 12 sed -i -e 's#\\documentclass#%\\documentclass#' -e '/{document}/ s#^#%#' ../subfiles/*.tex 13 sed -i 's#\\subfile{#\\input{#' chapters.tex appendices.tex 14 15 #latex2html -noimages -local_icons -no_footnode -split 4 -link 2 -dir ../html_LaTeX2HTML $* NEMO_manual 16 latex2html -debug -noreuse -init_file ../../l2hconf.pm -local_icons -dir ../build/html NEMO_manual 17 18 sed -i -e 's#%\\documentclass#\\documentclass#' -e '/{document}/ s#^%##' ../subfiles/*.tex 19 sed -i 's#\\input{#\\subfile{#' chapters.tex appendices.tex 18 20 cd - 19 21 22 sed -i -e 's#latin1#utf8#' \ 23 -e 's#\[\]{minted}#\[outputdir=../build\]{minted}#' \ 24 -e '/graphicspath/ s#{../../#{../#g' \ 25 global/packages.tex 26 20 27 exit 0 -
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO
- Property svn:ignore deleted
-
Property
svn:externals
set to
^/utils/figures/NEMO figures
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/main
- Property svn:ignore
-
old new 1 *.aux2 *.bbl3 *.blg4 *.dvi5 *.fdb*6 *.fls7 *.idx8 1 *.ilg 9 2 *.ind 10 *.log11 *.maf12 *.mtc*13 *.out14 *.pdf15 *.toc16 _minted-*
-
- Property svn:ignore
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles
- Property svn:ignore
-
old new 1 *.aux 2 *.bbl 3 *.blg 4 *.dvi 5 *.fdb* 6 *.fls 7 *.idx 1 *.ind 8 2 *.ilg 9 *.ind10 *.log11 *.maf12 *.mtc*13 *.out14 *.pdf15 *.toc16 _minted-*
-
- Property svn:ignore
-
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_ASM.tex
r10442 r11830 2 2 3 3 \begin{document} 4 % ================================================================ 5 % Chapter Assimilation increments (ASM) 6 % ================================================================ 4 7 5 \chapter{Apply Assimilation Increments (ASM)} 8 6 \label{chap:ASM} 9 7 10 Authors: D. Lea, M. Martin, K. Mogensen, A. Weaver, ... % do we keep 8 % {\em 4.0} & {\em D. J. Lea} & {\em \NEMO\ 4.0 updates} \\ 9 % {\em 3.4} & {\em D. J. Lea, M. Martin, K. Mogensen, A. Weaver} & {\em Initial version} \\ 11 10 12 \ minitoc11 \thispagestyle{plain} 13 12 14 \newpage 13 \chaptertoc 14 15 \paragraph{Changes record} ~\\ 16 17 {\footnotesize 18 \begin{tabularx}{\textwidth}{l||X|X} 19 Release & Author(s) & Modifications \\ 20 \hline 21 {\em 4.0} & {\em ...} & {\em ...} \\ 22 {\em 3.6} & {\em ...} & {\em ...} \\ 23 {\em 3.4} & {\em ...} & {\em ...} \\ 24 {\em <=3.4} & {\em ...} & {\em ...} 25 \end{tabularx} 26 } 27 28 \clearpage 15 29 16 30 The ASM code adds the functionality to apply increments to the model variables: temperature, salinity, 17 sea surface height, velocity and sea ice concentration. 31 sea surface height, velocity and sea ice concentration. 18 32 These are read into the model from a NetCDF file which may be produced by separate data assimilation code. 19 33 The code can also output model background fields which are used as an input to data assimilation code. 20 This is all controlled by the namelist \ textit{\ngn{nam\_asminc}}.34 This is all controlled by the namelist \nam{_asminc}{\_asminc}. 21 35 There is a brief description of all the namelist options provided. 22 36 To build the ASM code \key{asminc} must be set. 23 37 24 %=============================================================== 25 38 %% ================================================================================================= 26 39 \section{Direct initialization} 27 40 \label{sec:ASM_DI} … … 29 42 Direct initialization (DI) refers to the instantaneous correction of the model background state using 30 43 the analysis increment. 31 DI is used when \np{ln \_asmdin} is set to true.44 DI is used when \np{ln_asmdin}{ln\_asmdin} is set to true. 32 45 46 %% ================================================================================================= 33 47 \section{Incremental analysis updates} 34 48 \label{sec:ASM_IAU} … … 37 51 it may be preferable to introduce the increment gradually into the ocean model in order to 38 52 minimize spurious adjustment processes. 39 This technique is referred to as Incremental Analysis Updates (IAU) \citep{ Bloom_al_MWR96}.53 This technique is referred to as Incremental Analysis Updates (IAU) \citep{bloom.takacs.ea_MWR96}. 40 54 IAU is a common technique used with 3D assimilation methods such as 3D-Var or OI. 41 IAU is used when \np{ln \_asmiau} is set to true.55 IAU is used when \np{ln_asmiau}{ln\_asmiau} is set to true. 42 56 43 With IAU, the model state trajectory ${\ bf x}$ in the assimilation window ($t_{0} \leq t_{i} \leq t_{N}$)57 With IAU, the model state trajectory ${\mathbf x}$ in the assimilation window ($t_{0} \leq t_{i} \leq t_{N}$) 44 58 is corrected by adding the analysis increments for temperature, salinity, horizontal velocity and SSH as 45 59 additional tendency terms to the prognostic equations: 46 60 \begin{align*} 47 % \label{eq: wa_traj_iau}48 {\ bf x}^{a}(t_{i}) = M(t_{i}, t_{0})[{\bf x}^{b}(t_{0})] \; + \; F_{i} \delta \tilde{\bf x}^{a}61 % \label{eq:ASM_wa_traj_iau} 62 {\mathbf x}^{a}(t_{i}) = M(t_{i}, t_{0})[{\mathbf x}^{b}(t_{0})] \; + \; F_{i} \delta \tilde{\mathbf x}^{a} 49 63 \end{align*} 50 where $F_{i}$ is a weighting function for applying the increments $\delta\tilde{\ bf x}^{a}$ defined such that64 where $F_{i}$ is a weighting function for applying the increments $\delta\tilde{\mathbf x}^{a}$ defined such that 51 65 $\sum_{i=1}^{N} F_{i}=1$. 52 ${\ bf x}^b$ denotes the model initial state and ${\bf x}^a$ is the model state after the increments are applied.66 ${\mathbf x}^b$ denotes the model initial state and ${\mathbf x}^a$ is the model state after the increments are applied. 53 67 To control the adjustment time of the model to the increment, 54 68 the increment can be applied over an arbitrary sub-window, $t_{m} \leq t_{i} \leq t_{n}$, … … 56 70 Typically the increments are spread evenly over the full window. 57 71 In addition, two different weighting functions have been implemented. 58 The first function employs constant weights,72 The first function (namelist option \np{niaufn}{niaufn}=0) employs constant weights, 59 73 \begin{align} 60 \label{eq: F1_i}74 \label{eq:ASM_F1_i} 61 75 F^{(1)}_{i} 62 76 =\left\{ 63 77 \begin{array}{ll} 64 0 & {\ rm if} \; \; \; t_{i} < t_{m} \\65 1/M & {\ rm if} \; \; \; t_{m} < t_{i} \leq t_{n} \\66 0 & {\ rm if} \; \; \; t_{i} > t_{n}78 0 & {\mathrm if} \; \; \; t_{i} < t_{m} \\ 79 1/M & {\mathrm if} \; \; \; t_{m} < t_{i} \leq t_{n} \\ 80 0 & {\mathrm if} \; \; \; t_{i} > t_{n} 67 81 \end{array} 68 \right. 82 \right. 69 83 \end{align} 70 84 where $M = m-n$. 71 The second function employs peaked hat-like weights in order to give maximum weight in the centre of the sub-window,85 The second function (namelist option \np{niaufn}{niaufn}=1) employs peaked hat-like weights in order to give maximum weight in the centre of the sub-window, 72 86 with the weighting reduced linearly to a small value at the window end-points: 73 87 \begin{align} 74 \label{eq: F2_i}88 \label{eq:ASM_F2_i} 75 89 F^{(2)}_{i} 76 90 =\left\{ 77 91 \begin{array}{ll} 78 0 & {\ rm if} \; \; \; t_{i} < t_{m} \\79 \alpha \, i & {\ rm if} \; \; \; t_{m} \leq t_{i} \leq t_{M/2} \\80 \alpha \, (M - i +1) & {\ rm if} \; \; \; t_{M/2} < t_{i} \leq t_{n} \\81 0 & {\ rm if} \; \; \; t_{i} > t_{n}92 0 & {\mathrm if} \; \; \; t_{i} < t_{m} \\ 93 \alpha \, i & {\mathrm if} \; \; \; t_{m} \leq t_{i} \leq t_{M/2} \\ 94 \alpha \, (M - i +1) & {\mathrm if} \; \; \; t_{M/2} < t_{i} \leq t_{n} \\ 95 0 & {\mathrm if} \; \; \; t_{i} > t_{n} 82 96 \end{array} 83 97 \right. 84 98 \end{align} 85 where $\alpha^{-1} = \sum_{i=1}^{M/2} 2i$ and $M$ is assumed to be even. 86 The weights described by \autoref{eq: F2_i} provide a smoother transition of the analysis trajectory from87 one assimilation cycle to the next than that described by \autoref{eq: F1_i}.99 where $\alpha^{-1} = \sum_{i=1}^{M/2} 2i$ and $M$ is assumed to be even. 100 The weights described by \autoref{eq:ASM_F2_i} provide a smoother transition of the analysis trajectory from 101 one assimilation cycle to the next than that described by \autoref{eq:ASM_F1_i}. 88 102 89 %========================================================================== 90 % Divergence damping description %%% 103 %% ================================================================================================= 91 104 \section{Divergence damping initialisation} 92 105 \label{sec:ASM_div_dmp} 93 106 94 The velocity increments may be initialized by the iterative application of a divergence damping operator. 95 In iteration step $n$ new estimates of velocity increments $u^{n}_I$ and $v^{n}_I$ are updated by: 107 It is quite challenging for data assimilation systems to provide non-divergent velocity increments. 108 Applying divergent velocity increments will likely cause spurious vertical velocities in the model. This section describes a method to take velocity increments provided to \NEMO\ ($u^0_I$ and $v^0_I$) and adjust them by the iterative application of a divergence damping operator. The method is also described in \citet{dobricic.pinardi.ea_OS07}. 109 110 In iteration step $n$ (starting at $n=1$) new estimates of velocity increments $u^{n}_I$ and $v^{n}_I$ are updated by: 111 96 112 \begin{equation} 97 \label{eq: asm_dmp}113 \label{eq:ASM_dmp} 98 114 \left\{ 99 115 \begin{aligned} … … 105 121 \right., 106 122 \end{equation} 107 where 123 124 where the divergence is defined as 125 108 126 \[ 109 % \label{eq: asm_div}127 % \label{eq:ASM_div} 110 128 \chi^{n-1}_I = \frac{1}{e_{1t}\,e_{2t}\,e_{3t} } 111 129 \left( {\delta_i \left[ {e_{2u}\,e_{3u}\,u^{n-1}_I} \right] 112 130 +\delta_j \left[ {e_{1v}\,e_{3v}\,v^{n-1}_I} \right]} \right). 113 131 \] 114 By the application of \autoref{eq:asm_dmp} and \autoref{eq:asm_dmp} the divergence is filtered in each iteration, 132 133 By the application of \autoref{eq:ASM_dmp} the divergence is filtered in each iteration, 115 134 and the vorticity is left unchanged. 116 135 In the presence of coastal boundaries with zero velocity increments perpendicular to the coast … … 118 137 This type of the initialisation reduces the vertical velocity magnitude and 119 138 alleviates the problem of the excessive unphysical vertical mixing in the first steps of the model integration 120 \citep{ Talagrand_JAS72, Dobricic_al_OS07}.139 \citep{talagrand_JAS72, dobricic.pinardi.ea_OS07}. 121 140 Diffusion coefficients are defined as $A_D = \alpha e_{1t} e_{2t}$, where $\alpha = 0.2$. 122 The divergence damping is activated by assigning to \np{nn \_divdmp} in the \textit{nam\_asminc} namelist141 The divergence damping is activated by assigning to \np{nn_divdmp}{nn\_divdmp} in the \nam{_asminc}{\_asminc} namelist 123 142 a value greater than zero. 124 By choosing this value to be of the order of 100 the increments in 125 the vertical velocity will be significantly reduced. 143 This specifies the number of iterations of the divergence damping. Setting a value of the order of 100 will result in a significant reduction in the vertical velocity induced by the increments. 126 144 127 128 %========================================================================== 129 145 %% ================================================================================================= 130 146 \section{Implementation details} 131 147 \label{sec:ASM_details} 132 148 133 Here we show an example \n gn{namasm} namelist and the header of an example assimilation increments file on149 Here we show an example \nam{_asminc}{\_asminc} namelist and the header of an example assimilation increments file on 134 150 the ORCA2 grid. 135 151 136 %------------------------------------------namasm----------------------------------------------------- 137 % 138 \nlst{nam_asminc} 139 %------------------------------------------------------------------------------------------------------------- 152 \begin{listing} 153 \nlst{nam_asminc} 154 \caption{\forcode{&nam_asminc}} 155 \label{lst:nam_asminc} 156 \end{listing} 140 157 141 158 The header of an assimilation increments file produced using the NetCDF tool … … 177 194 \end{clines} 178 195 179 \biblio 180 181 \pindex 196 \subinc{\input{../../global/epilogue}} 182 197 183 198 \end{document} -
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DIA.tex
r10509 r11830 2 2 3 3 \begin{document} 4 % ================================================================ 5 % Chapter I/O & Diagnostics 6 % ================================================================ 4 7 5 \chapter{Output and Diagnostics (IOM, DIA, TRD, FLO)} 8 6 \label{chap:DIA} 9 7 10 \minitoc 11 12 \newpage 13 14 % ================================================================ 15 % Old Model Output 16 % ================================================================ 17 \section{Old model output (default)} 8 % {\em 4.0} & {\em Mirek Andrejczuk, Massimiliano Drudi} & {\em } \\ 9 % {\em } & {\em Dorotea Iovino, Nicolas Martin} & {\em } \\ 10 % {\em 3.6} & {\em Gurvan Madec, Sebastien Masson } & {\em } \\ 11 % {\em 3.4} & {\em Gurvan Madec, Rachid Benshila, Andrew Coward } & {\em } \\ 12 % {\em } & {\em Christian Ethe, Sebastien Masson } & {\em } \\ 13 14 \thispagestyle{plain} 15 16 \chaptertoc 17 18 \paragraph{Changes record} ~\\ 19 20 {\footnotesize 21 \begin{tabularx}{\textwidth}{l||X|X} 22 Release & Author(s) & Modifications \\ 23 \hline 24 {\em 4.0} & {\em ...} & {\em ...} \\ 25 {\em 3.6} & {\em ...} & {\em ...} \\ 26 {\em 3.4} & {\em ...} & {\em ...} \\ 27 {\em <=3.4} & {\em ...} & {\em ...} 28 \end{tabularx} 29 } 30 31 \clearpage 32 33 %% ================================================================================================= 34 \section{Model output} 18 35 \label{sec:DIA_io_old} 19 36 … … 25 42 the same run performed in one step. 26 43 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 the computer that 28 is to read it (in particular, 32 bits binary IEEE format must not be used for this file). 44 all the prognostic variables. 29 45 30 46 The output listing and file(s) are predefined but should be checked and eventually adapted to the user's needs. 31 The output listing is stored in the $ocean.output$file.32 The information is printed from within the code on the logical unit $numout$.47 The output listing is stored in the \textit{ocean.output} file. 48 The information is printed from within the code on the logical unit \texttt{numout}. 33 49 To locate these prints, use the UNIX command "\textit{grep -i numout}" in the source code directory. 34 50 … … 39 55 A complete description of the use of this I/O server is presented in the next section. 40 56 41 By default, \key{iomput} is not defined, 42 NEMO produces NetCDF with the old IOIPSL library 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 and 47 contain mean (or instantaneous if \key{diainstant} is defined) values over a regular period of 48 nn\_write time-steps (namelist parameter). 49 50 %\gmcomment{ % start of gmcomment 51 52 % ================================================================ 53 % Diagnostics 54 % ================================================================ 57 %\cmtgm{ % start of gmcomment 58 59 %% ================================================================================================= 55 60 \section{Standard model output (IOM)} 56 61 \label{sec:DIA_iom} 57 62 58 Since version 3.2, iomput is the NEMOoutput interface of choice.63 Since version 3.2, iomput is the \NEMO\ output interface of choice. 59 64 It has been designed to be simple to use, flexible and efficient. 60 The two main purposes of iomput are: 65 The two main purposes of iomput are: 61 66 62 67 \begin{enumerate} 63 \item 64 The complete and flexible control of the output files through external XML files adapted by 68 \item The complete and flexible control of the output files through external XML files adapted by 65 69 the user from standard templates. 66 \item 67 To achieve high performance and scalable output through the optional distribution of 70 \item To achieve high performance and scalable output through the optional distribution of 68 71 all diagnostic output related tasks to dedicated processes. 69 72 \end{enumerate} 70 73 71 The first functionality allows the user to specify, without code changes or recompilation, 74 The first functionality allows the user to specify, without code changes or recompilation, 72 75 aspects of the diagnostic output stream, such as: 73 76 74 77 \begin{itemize} 75 \item 76 The choice of output frequencies that can be different for each file (including real months and years). 77 \item 78 The choice of file contents; includes complete flexibility over which data are written in which files 78 \item The choice of output frequencies that can be different for each file (including real months and years). 79 \item The choice of file contents; includes complete flexibility over which data are written in which files 79 80 (the same data can be written in different files). 80 \item 81 The possibility to split output files at a chosen frequency. 82 \item 83 The possibility to extract a vertical or an horizontal subdomain. 84 \item 85 The choice of the temporal operation to perform, \eg: average, accumulate, instantaneous, min, max and once. 86 \item 87 Control over metadata via a large XML "database" of possible output fields. 81 \item The possibility to split output files at a chosen frequency. 82 \item The possibility to extract a vertical or an horizontal subdomain. 83 \item The choice of the temporal operation to perform, \eg: average, accumulate, instantaneous, min, max and once. 84 \item Control over metadata via a large XML "database" of possible output fields. 88 85 \end{itemize} 89 86 … … 91 88 in a very easy way. 92 89 All details of iomput functionalities are listed in the following subsections. 93 Examples of the XML files that control the outputs can be found in: \path{NEMOGCM/CONFIG/ORCA2_LIM/EXP00/iodef.xml}, 94 \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml}. \\ 90 Examples of the XML files that control the outputs can be found in: 91 \path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef.xml}, 92 \path{cfgs/SHARED/field_def_nemo-oce.xml}, 93 \path{cfgs/SHARED/field_def_nemo-pisces.xml}, 94 \path{cfgs/SHARED/field_def_nemo-ice.xml} and \path{cfgs/SHARED/domain_def_nemo.xml}. \\ 95 95 96 96 The second functionality targets output performance when running in parallel (\key{mpp\_mpi}). 97 Iomput provides the possibility to specify N dedicated I/O processes (in addition to the NEMOprocesses)97 Iomput provides the possibility to specify N dedicated I/O processes (in addition to the \NEMO\ processes) 98 98 to collect and write the outputs. 99 99 With an appropriate choice of N by the user, the bottleneck associated with the writing of 100 100 the output files can be greatly reduced. 101 101 102 In version 3.6, the iom\_putinterface depends on103 an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios- 1.0}{XIOS-1.0}104 (use of revision 618 or higher is required).102 In version 3.6, the \rou{iom\_put} interface depends on 103 an external code called \href{https://forge.ipsl.jussieu.fr/ioserver/browser/XIOS/branchs/xios-2.5}{XIOS-2.5} 104 %(use of revision 618 or higher is required). 105 105 This new IO server can take advantage of the parallel I/O functionality of NetCDF4 to 106 106 create a single output file and therefore to bypass the rebuilding phase. 107 107 Note that writing in parallel into the same NetCDF files requires that your NetCDF4 library is linked to 108 an HDF5 library that has been correctly compiled (\ie with the configure option $--$enable-parallel).108 an HDF5 library that has been correctly compiled (\ie\ with the configure option $--$enable-parallel). 109 109 Note that the files created by iomput through XIOS are incompatible with NetCDF3. 110 110 All post-processsing and visualization tools must therefore be compatible with NetCDF4 and not only NetCDF3. 111 111 112 112 Even if not using the parallel I/O functionality of NetCDF4, using N dedicated I/O servers, 113 where N is typically much less than the number of NEMOprocessors, will reduce the number of output files created.114 This can greatly reduce the post-processing burden usually associated with using large numbers of NEMOprocessors.113 where N is typically much less than the number of \NEMO\ processors, will reduce the number of output files created. 114 This can greatly reduce the post-processing burden usually associated with using large numbers of \NEMO\ processors. 115 115 Note that for smaller configurations, the rebuilding phase can be avoided, 116 116 even without a parallel-enabled NetCDF4 library, simply by employing only one dedicated I/O server. 117 117 118 %% ================================================================================================= 118 119 \subsection{XIOS: Reading and writing restart file} 119 120 120 XIOS may be used to read single file restart produced by NEMO. Currently only the variables written to121 file \forcode{numror} can be handled by XIOS. To activate restart reading using XIOS, set \np {ln\_xios\_read}\forcode{ = .true.}122 in \textit{namelist\_cfg}. This setting will be ignored when multiple restart files are present, and default NEMO123 functionality will be used for reading. There is no need to change iodef.xml file to use XIOS to read 124 restart, all definitions are done within the NEMO code. For high resolution configuration, however,121 XIOS may be used to read single file restart produced by \NEMO. Currently only the variables written to 122 file \forcode{numror} can be handled by XIOS. To activate restart reading using XIOS, set \np[=.true. ]{ln_xios_read}{ln\_xios\_read} 123 in \textit{namelist\_cfg}. This setting will be ignored when multiple restart files are present, and default \NEMO 124 functionality will be used for reading. There is no need to change iodef.xml file to use XIOS to read 125 restart, all definitions are done within the \NEMO\ code. For high resolution configuration, however, 125 126 there may be a need to add the following line in iodef.xml (xios context): 126 127 … … 129 130 \end{xmllines} 130 131 131 This variable sets timeout for reading. 132 133 If XIOS is to be used to read restart from file generated with an earlier NEMOversion (3.6 for instance),132 This variable sets timeout for reading. 133 134 If XIOS is to be used to read restart from file generated with an earlier \NEMO\ version (3.6 for instance), 134 135 dimension \forcode{z} defined in restart file must be renamed to \forcode{nav_lev}.\\ 135 136 136 XIOS can also be used to write NEMO restart. A namelist parameter \np{nn\_wxios} is used to determine the137 type of restart NEMO will write. If it is set to 0, default NEMO functionality will be used - each138 processor writes its own restart file; if it is set to 1 XIOS will write restart into a single file; 139 for \np {nn\_wxios = 2} the restart will be written by XIOS into multiple files, one for each XIOS server.140 Note, however, that \textbf{ NEMO will not read restart generated by XIOS when \np{nn\_wxios = 2}}. The restart will141 have to be rebuild before continuing the run. This option aims to reduce number of restart files generated by NEMO only,142 and may be useful when there is a need to change number of processors used to run simulation. 137 XIOS can also be used to write \NEMO\ restart. A namelist parameter \np{nn_wxios}{nn\_wxios} is used to determine the 138 type of restart \NEMO\ will write. If it is set to 0, default \NEMO\ functionality will be used - each 139 processor writes its own restart file; if it is set to 1 XIOS will write restart into a single file; 140 for \np[=2]{nn_wxios}{nn\_wxios} the restart will be written by XIOS into multiple files, one for each XIOS server. 141 Note, however, that \textbf{\NEMO\ will not read restart generated by XIOS when \np[=2]{nn_wxios}{nn\_wxios}}. The restart will 142 have to be rebuild before continuing the run. This option aims to reduce number of restart files generated by \NEMO\ only, 143 and may be useful when there is a need to change number of processors used to run simulation. 143 144 144 145 If an additional variable must be written to a restart file, the following steps are needed: 145 \begin{ description}146 \item[step 1:] add variable name to a list of restart variables (in subroutine \rou{iom\_set\_rst\_vars,} \mdl{iom}) and 147 define correct grid for the variable (\forcode{grid_N_3D} - 3D variable, \forcode{grid_N} - 2D variable, \forcode{grid_vector} - 146 \begin{enumerate} 147 \item Add variable name to a list of restart variables (in subroutine \rou{iom\_set\_rst\_vars,} \mdl{iom}) and 148 define correct grid for the variable (\forcode{grid_N_3D} - 3D variable, \forcode{grid_N} - 2D variable, \forcode{grid_vector} - 148 149 1D variable, \forcode{grid_scalar} - scalar), 149 \item[step 2:] add variable to the list of fields written by restart. This can be done either in subroutine 150 \rou{iom\_set\_rstw\_core} (\mdl{iom}) or by calling \rou{iom\_set\_rstw\_active} (\mdl{iom}) with the name of a variable 151 as an argument. This convention follows approach for writing restart using iom, where variables are 150 \item Add variable to the list of fields written by restart. This can be done either in subroutine 151 \rou{iom\_set\_rstw\_core} (\mdl{iom}) or by calling \rou{iom\_set\_rstw\_active} (\mdl{iom}) with the name of a variable 152 as an argument. This convention follows approach for writing restart using iom, where variables are 152 153 written either by \rou{rst\_write} or by calling \rou{iom\_rstput} from individual routines. 153 \end{description} 154 154 \end{enumerate} 155 155 156 156 An older versions of XIOS do not support reading functionality. It's recommended to use at least XIOS2@1451. 157 157 158 158 %% ================================================================================================= 159 159 \subsection{XIOS: XML Inputs-Outputs Server} 160 160 161 %% ================================================================================================= 161 162 \subsubsection{Attached or detached mode?} 162 163 … … 168 169 \xmlline|<variable id="using_server" type="bool"></variable>| 169 170 170 The {\tt using\_server} setting determines whether or not the server will be used in \textit{attached mode} 171 (as a library) [{\tt> false <}] or in \textit{detached mode} 172 (as an external executable on N additional, dedicated cpus) [{\tt > true <}]. 173 The \textit{attached mode} is simpler to use but much less efficient for massively parallel applications. 171 The \texttt{using\_server} setting determines whether or not the server will be used in 172 \textit{attached mode} 173 (as a library) [\texttt{> false <}] or in \textit{detached mode} 174 (as an external executable on N additional, dedicated cpus) [\texttt{ > true <}]. 175 The \textit{attached mode} is simpler to use but much less efficient for 176 massively parallel applications. 174 177 The type of each file can be either ''multiple\_file'' or ''one\_file''. 175 178 176 179 In \textit{attached mode} and if the type of file is ''multiple\_file'', 177 then each NEMOprocess will also act as an IO server and produce its own set of output files.180 then each \NEMO\ process will also act as an IO server and produce its own set of output files. 178 181 Superficially, this emulates the standard behaviour in previous versions. 179 182 However, the subdomain written out by each process does not correspond to … … 187 190 write to its own set of output files. 188 191 If the ''one\_file'' option is chosen then all XIOS processes will collect their longitudinal strips and 189 write (in parallel) to a single output file. 192 write (in parallel) to a single output file. 190 193 Note running in detached mode requires launching a Multiple Process Multiple Data (MPMD) parallel job. 191 194 The following subsection provides a typical example but the syntax will vary in different MPP environments. 192 195 196 %% ================================================================================================= 193 197 \subsubsection{Number of cpu used by XIOS in detached mode} 194 198 195 199 The number of cores used by the XIOS is specified when launching the model. 196 The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of 197 cores dedicated to NEMO.200 The number of cores dedicated to XIOS should be from \texttildelow1/10 to \texttildelow1/50 of the number of 201 cores dedicated to \NEMO. 198 202 Some manufacturers suggest using O($\sqrt{N}$) dedicated IO processors for N processors but 199 this is a general recommendation and not specific to NEMO.203 this is a general recommendation and not specific to \NEMO. 200 204 It is difficult to provide precise recommendations because the optimal choice will depend on 201 the particular hardware properties of the target system 205 the particular hardware properties of the target system 202 206 (parallel filesystem performance, available memory, memory bandwidth etc.) 203 207 and the volume and frequency of data to be created. … … 205 209 \cmd|mpirun -np 62 ./nemo.exe : -np 2 ./xios_server.exe| 206 210 211 %% ================================================================================================= 207 212 \subsubsection{Control of XIOS: the context in iodef.xml} 208 213 209 As well as the {\tt using\_server} flag, other controls on the use of XIOS are set in the XIOS context in iodef.xml. 214 As well as the \texttt{using\_server} flag, other controls on the use of XIOS are set in 215 the XIOS context in \textit{iodef.xml}. 210 216 See the XML basics section below for more details on XML syntax and rules. 211 217 212 218 \begin{table} 213 \scriptsize214 219 \begin{tabularx}{\textwidth}{|lXl|} 215 220 \hline … … 220 225 \hline 221 226 buffer\_size & 222 buffer size used by XIOS to send data from NEMOto XIOS.227 buffer size used by XIOS to send data from \NEMO\ to XIOS. 223 228 Larger is more efficient. 224 229 Note that needed/used buffer sizes are summarized at the end of the job & … … 226 231 \hline 227 232 buffer\_server\_factor\_size & 228 ratio between NEMOand XIOS buffer size.233 ratio between \NEMO\ and XIOS buffer size. 229 234 Should be 2. & 230 235 2 \\ … … 243 248 \hline 244 249 oasis\_codes\_id & 245 when using oasis, define the identifier of NEMOin the namcouple.250 when using oasis, define the identifier of \NEMO\ in the namcouple. 246 251 Note that the identifier of XIOS is xios.x & 247 252 oceanx \\ … … 250 255 \end{table} 251 256 257 %% ================================================================================================= 252 258 \subsection{Practical issues} 253 259 260 %% ================================================================================================= 254 261 \subsubsection{Installation} 255 262 256 As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with NEMO.263 As mentioned, XIOS is supported separately and must be downloaded and compiled before it can be used with \NEMO. 257 264 See the installation guide on the \href{http://forge.ipsl.jussieu.fr/ioserver/wiki}{XIOS} wiki for help and guidance. 258 NEMO will need to link to the compiled XIOS library. 259 The \href{https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInterfacing/InputsOutputs#Inputs-OutputsusingXIOS} 260 {XIOS with NEMO} guide provides an example illustration of how this can be achieved. 261 265 \NEMO\ will need to link to the compiled XIOS library. 266 The \href{https://forge.ipsl.jussieu.fr/nemo/chrome/site/doc/NEMO/guide/html/install.html#extract-and-install-xios} 267 {Extract and install XIOS} guide provides an example illustration of how this can be achieved. 268 269 %% ================================================================================================= 262 270 \subsubsection{Add your own outputs} 263 271 … … 268 276 269 277 \begin{enumerate} 270 \item[1.] 271 in NEMO code, add a \forcode{CALL iom\_put( 'identifier', array )} where you want to output a 2D or 3D array. 272 \item[2.] 273 If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in 278 \item in \NEMO\ code, add a \forcode{CALL iom_put( 'identifier', array )} where you want to output a 2D or 3D array. 279 \item If necessary, add \forcode{USE iom ! I/O manager library} to the list of used modules in 274 280 the upper part of your module. 275 \item[3.] 276 in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code 281 \item in the field\_def.xml file, add the definition of your variable using the same identifier you used in the f90 code 277 282 (see subsequent sections for a details of the XML syntax and rules). 278 283 For example: 279 280 284 \begin{xmllines} 281 285 <field_definition> 282 286 <field_group id="grid_T" grid_ref="grid_T_3D"> <!-- T grid --> 283 287 ... 284 <field id="identifier" long_name="blabla" ... /> 288 <field id="identifier" long_name="blabla" ... /> 285 289 ... 286 </field_definition> 287 \end{xmllines} 288 290 </field_definition> 291 \end{xmllines} 289 292 Note your definition must be added to the field\_group whose reference grid is consistent with the size of 290 293 the array passed to iomput. … … 293 296 (iom\_set\_domain\_attr and iom\_set\_axis\_attr in \mdl{iom}) or defined in the domain\_def.xml file. 294 297 \eg: 295 296 298 \begin{xmllines} 297 299 <grid id="grid_T_3D" domain_ref="grid_T" axis_ref="deptht"/> 298 300 \end{xmllines} 299 300 Note, if your array is computed within the surface module each \np{nn\_fsbc} time\_step, 301 Note, if your array is computed within the surface module each \np{nn_fsbc}{nn\_fsbc} time\_step, 301 302 add the field definition within the field\_group defined with the id "SBC": 302 303 \xmlcode{<field_group id="SBC" ...>} which has been defined with the correct frequency of operations 303 304 (iom\_set\_field\_attr in \mdl{iom}) 304 \item[4.] 305 add your field in one of the output files defined in iodef.xml 305 \item add your field in one of the output files defined in iodef.xml 306 306 (again see subsequent sections for syntax and rules) 307 308 \begin{xmllines} 309 <file id="file1" .../> 307 \begin{xmllines} 308 <file id="file1" .../> 310 309 ... 311 <field field_ref="identifier" /> 310 <field field_ref="identifier" /> 312 311 ... 313 </file> 314 \end{xmllines} 315 312 </file> 313 \end{xmllines} 316 314 \end{enumerate} 317 315 316 %% ================================================================================================= 318 317 \subsection{XML fundamentals} 319 318 319 %% ================================================================================================= 320 320 \subsubsection{ XML basic rules} 321 321 … … 327 327 See \href{http://www.xmlnews.org/docs/xml-basics.html}{here} for more details. 328 328 329 \subsubsection{Structure of the XML file used in NEMO} 329 %% ================================================================================================= 330 \subsubsection{Structure of the XML file used in \NEMO} 330 331 331 332 The XML file used in XIOS is structured by 7 families of tags: … … 334 335 335 336 \begin{table} 336 \scriptsize337 337 \begin{tabular*}{\textwidth}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|} 338 338 \hline … … 366 366 367 367 \begin{table} 368 \scriptsize369 368 \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|} 370 369 \hline … … 376 375 \xmlcode{<context id="xios" ... >} \\ 377 376 \hline 378 context nemo & context containing IO information for NEMO (mother grid when using AGRIF) &377 context nemo & context containing IO information for \NEMO\ (mother grid when using AGRIF) & 379 378 \xmlcode{<context id="nemo" ... >} \\ 380 379 \hline 381 context 1\_nemo & context containing IO information for NEMO child grid 1 (when using AGRIF) &380 context 1\_nemo & context containing IO information for \NEMO\ child grid 1 (when using AGRIF) & 382 381 \xmlcode{<context id="1_nemo" ... >} \\ 383 382 \hline 384 context n\_nemo & context containing IO information for NEMO child grid n (when using AGRIF) &383 context n\_nemo & context containing IO information for \NEMO\ child grid n (when using AGRIF) & 385 384 \xmlcode{<context id="n_nemo" ... >} \\ 386 385 \hline … … 391 390 392 391 \begin{table} 393 \scriptsize394 392 \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|} 395 393 \hline … … 407 405 \end{table} 408 406 409 \noindent Each context tag related to NEMO (mother or child grids) is divided into 5 parts407 \noindent Each context tag related to \NEMO\ (mother or child grids) is divided into 5 parts 410 408 (that can be defined in any order): 411 409 412 410 \begin{table} 413 \scriptsize414 411 \begin{tabular}{|p{0.15\textwidth}p{0.4\textwidth}p{0.35\textwidth}|} 415 412 \hline … … 436 433 \end{table} 437 434 435 %% ================================================================================================= 438 436 \subsubsection{Nesting XML files} 439 437 … … 441 439 The inclusion of XML files into the main XML file can be done through the attribute src: 442 440 \xmlline|<context src="./nemo_def.xml" />| 443 444 \noindent In NEMO, by default, the field and domain definition is done in 2 separate files: 445 \path{NEMOGCM/CONFIG/SHARED/field_def.xml} and \path{NEMOGCM/CONFIG/SHARED/domain_def.xml} that 441 442 \noindent In \NEMO, by default, the field definition is done in 3 separate files ( 443 \path{cfgs/SHARED/field_def_nemo-oce.xml}, 444 \path{cfgs/SHARED/field_def_nemo-pisces.xml} and 445 \path{cfgs/SHARED/field_def_nemo-ice.xml} ) and the domain definition is done in another file ( \path{cfgs/SHARED/domain_def_nemo.xml} ) 446 that 446 447 are included in the main iodef.xml file through the following commands: 447 448 \begin{xmllines} 448 < field_definition src="./field_def.xml"/>449 <domain_definition src="./domain_def.xml" /> 450 \end{xmllines} 451 449 <context id="nemo" src="./context_nemo.xml"/> 450 \end{xmllines} 451 452 %% ================================================================================================= 452 453 \subsubsection{Use of inheritance} 453 454 … … 462 463 \begin{xmllines} 463 464 <field_definition operation="average" > 464 <field id="sst" /> <!-- averaged sst --> 465 <field id="sss" operation="instant"/> <!-- instantaneous sss --> 466 </field_definition> 465 <field id="sst" /> <!-- averaged sst --> 466 <field id="sss" operation="instant"/> <!-- instantaneous sss --> 467 </field_definition> 467 468 \end{xmllines} 468 469 … … 481 482 </field_definition> 482 483 <file_definition> 483 <file id="myfile" output_freq="1d" /> 484 <file id="myfile" output_freq="1d" /> 484 485 <field field_ref="sst" /> <!-- default def --> 485 486 <field field_ref="sss" long_name="my description" /> <!-- overwrite --> 486 487 </file> 487 </file_definition> 488 </file_definition> 488 489 \end{xmllines} 489 490 490 491 Inherit (and overwrite, if needed) the attributes of a tag you are refering to. 491 492 493 %% ================================================================================================= 492 494 \subsubsection{Use of groups} 493 495 … … 508 510 509 511 Secondly, the group can be used to replace a list of elements. 510 Several examples of groups of fields are proposed at the end of the file \path{CONFIG/SHARED/field_def.xml}. 512 Several examples of groups of fields are proposed at the end of the XML field files ( 513 \path{cfgs/SHARED/field_def_nemo-oce.xml}, 514 \path{cfgs/SHARED/field_def_nemo-pisces.xml} and 515 \path{cfgs/SHARED/field_def_nemo-ice.xml} ) . 511 516 For example, a short list of the usual variables related to the U grid: 512 517 … … 514 519 <field_group id="groupU" > 515 520 <field field_ref="uoce" /> 516 <field field_ref="s uoce" />521 <field field_ref="ssu" /> 517 522 <field field_ref="utau" /> 518 523 </field_group> … … 525 530 <field_group group_ref="groupU" /> 526 531 <field field_ref="uocetr_eff" /> <!-- add another field --> 527 </file> 528 \end{xmllines} 529 532 </file> 533 \end{xmllines} 534 535 %% ================================================================================================= 530 536 \subsection{Detailed functionalities} 531 537 … … 533 539 the new functionalities offered by the XML interface of XIOS. 534 540 541 %% ================================================================================================= 535 542 \subsubsection{Define horizontal subdomains} 536 543 537 544 Horizontal subdomains are defined through the attributs zoom\_ibegin, zoom\_jbegin, zoom\_ni, zoom\_nj of 538 545 the tag family domain. 539 It must therefore be done in the domain part of the XML file. 540 For example, in \path{ CONFIG/SHARED/domain_def.xml}, we provide the following example of a definition of546 It must therefore be done in the domain part of the XML file. 547 For example, in \path{cfgs/SHARED/domain_def.xml}, we provide the following example of a definition of 541 548 a 5 by 5 box with the bottom left corner at point (10,10). 542 549 543 550 \begin{xmllines} 544 <domain _group id="grid_T">545 < domain id="myzoom" zoom_ibegin="10" zoom_jbegin="10" zoom_ni="5" zoom_nj="5" />551 <domain id="myzoomT" domain_ref="grid_T"> 552 <zoom_domain ibegin="10" jbegin="10" ni="5" nj="5" /> 546 553 \end{xmllines} 547 554 … … 551 558 \begin{xmllines} 552 559 <file id="myfile_vzoom" output_freq="1d" > 553 <field field_ref="toce" domain_ref="myzoom "/>560 <field field_ref="toce" domain_ref="myzoomT"/> 554 561 </file> 555 562 \end{xmllines} 556 563 557 Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 564 Moorings are seen as an extrem case corresponding to a 1 by 1 subdomain. 558 565 The Equatorial section, the TAO, RAMA and PIRATA moorings are already registered in the code and 559 566 can therefore be outputted without taking care of their (i,j) position in the grid. … … 568 575 \end{xmllines} 569 576 570 Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if 571 you use the ''multiple\_file'' type for your output files, 572 you will endup with several files you will need to rebuild using unprovided tools (like ncpdq and ncrcat, 577 Note that if the domain decomposition used in XIOS cuts the subdomain in several parts and if 578 you use the ''multiple\_file'' type for your output files, 579 you will endup with several files you will need to rebuild using unprovided tools (like ncpdq and ncrcat, 573 580 \href{http://nco.sourceforge.net/nco.html#Concatenation}{see nco manual}). 574 581 We are therefore advising to use the ''one\_file'' type in this case. 575 582 583 %% ================================================================================================= 576 584 \subsubsection{Define vertical zooms} 577 585 578 Vertical zooms are defined through the attributs zoom\_begin and zoom\_ endof the tag family axis.586 Vertical zooms are defined through the attributs zoom\_begin and zoom\_n of the tag family axis. 579 587 It must therefore be done in the axis part of the XML file. 580 For example, in \path{NEMOGCM/CONFIG/ORCA2_LIM/iodef_demo.xml}, we provide the following example: 581 582 \begin{xmllines} 583 <axis_group id="deptht" long_name="Vertical T levels" unit="m" positive="down" > 584 <axis id="deptht" /> 585 <axis id="deptht_myzoom" zoom_begin="1" zoom_end="10" /> 588 For example, in \path{cfgs/ORCA2_ICE_PISCES/EXPREF/iodef_demo.xml}, we provide the following example: 589 590 \begin{xmllines} 591 <axis_definition> 592 <axis id="deptht" long_name="Vertical T levels" unit="m" positive="down" /> 593 <axis id="deptht_zoom" azix_ref="deptht" > 594 <zoom_axis zoom_begin="1" zoom_n="10" /> 595 </axis> 586 596 \end{xmllines} 587 597 … … 595 605 \end{xmllines} 596 606 607 %% ================================================================================================= 597 608 \subsubsection{Control of the output file names} 598 609 … … 601 612 602 613 \begin{xmllines} 603 <file_group id="1d" output_freq="1d" name="myfile_1d" > 614 <file_group id="1d" output_freq="1d" name="myfile_1d" > 604 615 <file id="myfileA" name_suffix="_AAA" > <!-- will create file "myfile_1d_AAA" --> 605 616 ... … … 620 631 621 632 \begin{table} 622 \scriptsize623 633 \begin{tabularx}{\textwidth}{|lX|} 624 634 \hline … … 656 666 \end{table} 657 667 658 \noindent For example, 668 \noindent For example, 659 669 \xmlline|<file id="myfile_hzoom" name="myfile_@expname@_@startdate@_freq@freq@" output_freq="1d" >| 660 670 … … 668 678 \noindent will give the following file name radical: \ifile{myfile\_ORCA2\_19891231\_freq1d} 669 679 670 \subsubsection{Other controls of the XML attributes from NEMO} 671 672 The values of some attributes are defined by subroutine calls within NEMO 680 %% ================================================================================================= 681 \subsubsection{Other controls of the XML attributes from \NEMO} 682 683 The values of some attributes are defined by subroutine calls within \NEMO 673 684 (calls to iom\_set\_domain\_attr, iom\_set\_axis\_attr and iom\_set\_field\_attr in \mdl{iom}). 674 685 Any definition given in the XML file will be overwritten. … … 681 692 682 693 \begin{table} 683 \scriptsize 684 \begin{tabularx}{\textwidth}{|X|c|c|c|} 694 \begin{tabular}{|l|c|c|} 685 695 \hline 686 696 tag ids affected by automatic definition of some of their attributes & 687 697 name attribute & 688 attribute value \\698 attribute value \\ 689 699 \hline 690 700 \hline 691 701 field\_definition & 692 702 freq\_op & 693 \np{rn \_rdt}\\703 \np{rn_rdt}{rn\_rdt} \\ 694 704 \hline 695 705 SBC & 696 706 freq\_op & 697 \np{rn \_rdt} $\times$ \np{nn\_fsbc}\\707 \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_fsbc}{nn\_fsbc} \\ 698 708 \hline 699 709 ptrc\_T & 700 710 freq\_op & 701 \np{rn \_rdt} $\times$ \np{nn\_dttrc}\\711 \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_dttrc}{nn\_dttrc} \\ 702 712 \hline 703 713 diad\_T & 704 714 freq\_op & 705 \np{rn \_rdt} $\times$ \np{nn\_dttrc}\\715 \np{rn_rdt}{rn\_rdt} $\times$ \np{nn_dttrc}{nn\_dttrc} \\ 706 716 \hline 707 717 EqT, EqU, EqW & 708 718 jbegin, ni, & 709 according to the grid \\710 &719 according to the grid \\ 720 & 711 721 name\_suffix & 712 \\722 \\ 713 723 \hline 714 724 TAO, RAMA and PIRATA moorings & 715 725 zoom\_ibegin, zoom\_jbegin, & 716 according to the grid \\717 &726 according to the grid \\ 727 & 718 728 name\_suffix & 719 \\720 \hline 721 \end{tabular x}729 \\ 730 \hline 731 \end{tabular} 722 732 \end{table} 723 733 734 %% ================================================================================================= 724 735 \subsubsection{Advanced use of XIOS functionalities} 725 736 737 %% ================================================================================================= 726 738 \subsection{XML reference tables} 727 \label{subsec: IOM_xmlref}739 \label{subsec:DIA_IOM_xmlref} 728 740 729 741 \begin{enumerate} 730 \item 731 Simple computation: directly define the computation when refering to the variable in the file definition. 742 \item Simple computation: directly define the computation when refering to the variable in the file definition. 732 743 733 744 \begin{xmllines} … … 737 748 \end{xmllines} 738 749 739 \item 740 Simple computation: define a new variable and use it in the file definition. 750 \item Simple computation: define a new variable and use it in the file definition. 741 751 742 752 in field\_definition: … … 755 765 sst2 won't be evaluated. 756 766 757 \item 758 Change of variable precision: 767 \item Change of variable precision: 759 768 760 769 \begin{xmllines} … … 765 774 \end{xmllines} 766 775 767 Note that, then the code is crashing, writting real4 variables forces a numerical conve ction from776 Note that, then the code is crashing, writting real4 variables forces a numerical conversion from 768 777 real8 to real4 which will create an internal error in NetCDF and will avoid the creation of the output files. 769 778 Forcing double precision outputs with prec="8" (for example in the field\_definition) will avoid this problem. 770 779 771 \item 772 add user defined attributes: 773 774 \begin{xmllines} 775 <file_group id="1d" output_freq="1d" output_level="10" enabled=".true."> <!-- 1d files --> 780 \item add user defined attributes: 781 782 \begin{xmllines} 783 <file_group id="1d" output_freq="1d" output_level="10" enabled=".true."> <!-- 1d files --> 776 784 <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" > 777 785 <field field_ref="sst" name="tos" > … … 782 790 <variable id="my_global_attribute" type="string" > blabla_global </variable> 783 791 </file> 784 </file_group> 785 \end{xmllines} 786 787 \item 788 use of the ``@'' function: example 1, weighted temporal average 792 </file_group> 793 \end{xmllines} 794 795 \item use of the ``@'' function: example 1, weighted temporal average 789 796 790 797 - define a new variable in field\_definition … … 797 804 798 805 \begin{xmllines} 799 <file_group id="5d" output_freq="5d" output_level="10" enabled=".true." > <!-- 5d files --> 806 <file_group id="5d" output_freq="5d" output_level="10" enabled=".true." > <!-- 5d files --> 800 807 <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" > 801 808 <field field_ref="toce" operation="instant" freq_op="5d" > @toce_e3t / @e3t </field> 802 809 </file> 803 </file_group> 810 </file_group> 804 811 \end{xmllines} 805 812 … … 814 821 Note that in this case, freq\_op must be equal to the file output\_freq. 815 822 816 \item 817 use of the ``@'' function: example 2, monthly SSH standard deviation 823 \item use of the ``@'' function: example 2, monthly SSH standard deviation 818 824 819 825 - define a new variable in field\_definition … … 826 832 827 833 \begin{xmllines} 828 <file_group id="1m" output_freq="1m" output_level="10" enabled=".true." > <!-- 1m files --> 834 <file_group id="1m" output_freq="1m" output_level="10" enabled=".true." > <!-- 1m files --> 829 835 <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" > 830 <field field_ref="ssh" name="sshstd" long_name="sea_surface_temperature_standard_deviation" 836 <field field_ref="ssh" name="sshstd" long_name="sea_surface_temperature_standard_deviation" 831 837 operation="instant" freq_op="1m" > 832 838 sqrt( @ssh2 - @ssh * @ssh ) 833 839 </field> 834 840 </file> 835 </file_group> 841 </file_group> 836 842 \end{xmllines} 837 843 … … 840 846 here we use the default, average. 841 847 So, in the above case, @ssh2 will do the monthly mean of ssh*ssh. 842 Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'': 848 Operation="instant" refers to the temporal operation to be performed on the field ''sqrt( @ssh2 - @ssh * @ssh )'': 843 849 here the temporal average is alreday done by the ``@'' function so we just use instant. 844 850 field\_ref="ssh" means that attributes not explicitely defined, are inherited from ssh field. 845 851 Note that in this case, freq\_op must be equal to the file output\_freq. 846 852 847 \item 848 use of the ``@'' function: example 3, monthly average of SST diurnal cycle 853 \item use of the ``@'' function: example 3, monthly average of SST diurnal cycle 849 854 850 855 - define 2 new variables in field\_definition … … 858 863 859 864 \begin{xmllines} 860 <file_group id="1m" output_freq="1m" output_level="10" enabled=".true." > <!-- 1m files --> 865 <file_group id="1m" output_freq="1m" output_level="10" enabled=".true." > <!-- 1m files --> 861 866 <file id="file1" name_suffix="_grid_T" description="ocean T grid variables" > 862 867 <field field_ref="sst" name="sstdcy" long_name="amplitude of sst diurnal cycle" operation="average" freq_op="1d" > … … 864 869 </field> 865 870 </file> 866 </file_group> 871 </file_group> 867 872 \end{xmllines} 868 873 … … 877 882 field\_ref="sst" means that attributes not explicitely defined, are inherited from sst field. 878 883 884 %% ================================================================================================= 879 885 \subsubsection{Tag list per family} 880 886 881 887 \begin{table} 882 \scriptsize883 888 \begin{tabularx}{\textwidth}{|l|X|X|l|X|} 884 889 \hline … … 903 908 \hline 904 909 \end{tabularx} 905 \caption{ Context tags}910 \caption{XIOS: context tags} 906 911 \end{table} 907 912 908 913 \begin{table} 909 \scriptsize910 914 \begin{tabularx}{\textwidth}{|l|X|X|X|l|} 911 915 \hline … … 938 942 \hline 939 943 \end{tabularx} 940 \caption{ Field tags ("\tt{field\_*}")}944 \caption{XIOS: field tags ("\texttt{field\_*}")} 941 945 \end{table} 942 946 943 947 \begin{table} 944 \scriptsize945 948 \begin{tabularx}{\textwidth}{|l|X|X|X|l|} 946 949 \hline … … 974 977 \hline 975 978 \end{tabularx} 976 \caption{ File tags ("\tt{file\_*}")}979 \caption{XIOS: file tags ("\texttt{file\_*}")} 977 980 \end{table} 978 981 979 982 \begin{table} 980 \scriptsize981 983 \begin{tabularx}{\textwidth}{|l|X|X|X|X|} 982 984 \hline … … 1007 1009 \hline 1008 1010 \end{tabularx} 1009 \caption{ Axis tags ("\tt{axis\_*}")}1011 \caption{XIOS: axis tags ("\texttt{axis\_*}")} 1010 1012 \end{table} 1011 1013 1012 1014 \begin{table} 1013 \scriptsize1014 1015 \begin{tabularx}{\textwidth}{|l|X|X|X|X|} 1015 1016 \hline … … 1040 1041 \hline 1041 1042 \end{tabularx} 1042 \caption{ Domain tags ("\tt{domain\_*)}"}1043 \caption{XIOS: domain tags ("\texttt{domain\_*)}"} 1043 1044 \end{table} 1044 1045 1045 1046 \begin{table} 1046 \scriptsize1047 1047 \begin{tabularx}{\textwidth}{|l|X|X|X|X|} 1048 1048 \hline … … 1073 1073 \hline 1074 1074 \end{tabularx} 1075 \caption{ Grid tags ("\tt{grid\_*}")}1075 \caption{XIOS: grid tags ("\texttt{grid\_*}")} 1076 1076 \end{table} 1077 1077 1078 %% ================================================================================================= 1078 1079 \subsubsection{Attributes list per family} 1079 1080 1080 1081 \begin{table} 1081 \scriptsize1082 1082 \begin{tabularx}{\textwidth}{|l|X|l|l|} 1083 1083 \hline … … 1114 1114 \hline 1115 1115 \end{tabularx} 1116 \caption{ Reference attributes ("\tt{*\_ref}")}1116 \caption{XIOS: reference attributes ("\texttt{*\_ref}")} 1117 1117 \end{table} 1118 1118 1119 1119 \begin{table} 1120 \scriptsize1121 1120 \begin{tabularx}{\textwidth}{|l|X|l|l|} 1122 1121 \hline … … 1150 1149 \hline 1151 1150 \end{tabularx} 1152 \caption{ Domain attributes ("\tt{zoom\_*}")}1151 \caption{XIOS: domain attributes ("\texttt{zoom\_*}")} 1153 1152 \end{table} 1154 1153 1155 1154 \begin{table} 1156 \scriptsize1157 1155 \begin{tabularx}{\textwidth}{|l|X|l|l|} 1158 1156 \hline … … 1205 1203 \hline 1206 1204 \end{tabularx} 1207 \caption{ File attributes}1205 \caption{XIOS: file attributes} 1208 1206 \end{table} 1209 1207 1210 1208 \begin{table} 1211 \scriptsize1212 1209 \begin{tabularx}{\textwidth}{|l|X|l|l|} 1213 1210 \hline … … 1254 1251 \hline 1255 1252 \end{tabularx} 1256 \caption{ Field attributes}1253 \caption{XIOS: field attributes} 1257 1254 \end{table} 1258 1255 1259 1256 \begin{table} 1260 \scriptsize1261 1257 \begin{tabularx}{\textwidth}{|l|X|X|X|} 1262 1258 \hline … … 1313 1309 \hline 1314 1310 \end{tabularx} 1315 \caption{ Miscellaneous attributes}1311 \caption{XIOS: miscellaneous attributes} 1316 1312 \end{table} 1317 1313 1314 %% ================================================================================================= 1318 1315 \subsection{CF metadata standard compliance} 1319 1316 1320 Output from the XIOS -1.0 IO server is compliant with1317 Output from the XIOS IO server is compliant with 1321 1318 \href{http://cfconventions.org/Data/cf-conventions/cf-conventions-1.5/build/cf-conventions.html}{version 1.5} of 1322 the CF metadata standard. 1319 the CF metadata standard. 1323 1320 Therefore while a user may wish to add their own metadata to the output files (as demonstrated in example 4 of 1324 section \autoref{subsec: IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard.1321 section \autoref{subsec:DIA_IOM_xmlref}) the metadata should, for the most part, comply with the CF-1.5 standard. 1325 1322 1326 1323 Some metadata that may significantly increase the file size (horizontal cell areas and vertices) are controlled by 1327 the namelist parameter \np{ln \_cfmeta} in the \ngn{namrun} namelist.1324 the namelist parameter \np{ln_cfmeta}{ln\_cfmeta} in the \nam{run}{run} namelist. 1328 1325 This must be set to true if these metadata are to be included in the output files. 1329 1326 1330 1331 % ================================================================ 1332 % NetCDF4 support 1333 % ================================================================ 1334 \section{NetCDF4 support (\protect\key{netcdf4})} 1327 %% ================================================================================================= 1328 \section[NetCDF4 support (\texttt{\textbf{key\_netcdf4}})]{NetCDF4 support (\protect\key{netcdf4})} 1335 1329 \label{sec:DIA_nc4} 1336 1330 … … 1340 1334 Chunking and compression can lead to significant reductions in file sizes for a small runtime overhead. 1341 1335 For a fuller discussion on chunking and other performance issues the reader is referred to 1342 the NetCDF4 documentation found \href{http ://www.unidata.ucar.edu/software/netcdf/docs/netcdf.html#Chunking}{here}.1336 the NetCDF4 documentation found \href{https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_perf_chunking.html}{here}. 1343 1337 1344 1338 The new features are only available when the code has been linked with a NetCDF4 library … … 1346 1340 Datasets created with chunking and compression are not backwards compatible with NetCDF3 "classic" format but 1347 1341 most analysis codes can be relinked simply with the new libraries and will then read both NetCDF3 and NetCDF4 files. 1348 NEMO executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by 1349 setting the \np{ln\_nc4zip} logical to false in the \textit{namnc4} namelist: 1350 1351 %------------------------------------------namnc4---------------------------------------------------- 1352 1353 \nlst{namnc4} 1354 %------------------------------------------------------------------------------------------------------------- 1342 \NEMO\ executables linked with NetCDF4 libraries can be made to produce NetCDF3 files by 1343 setting the \np{ln_nc4zip}{ln\_nc4zip} logical to false in the \nam{nc4}{nc4} namelist: 1344 1345 \begin{listing} 1346 \nlst{namnc4} 1347 \caption{\forcode{&namnc4}} 1348 \label{lst:namnc4} 1349 \end{listing} 1355 1350 1356 1351 If \key{netcdf4} has not been defined, these namelist parameters are not read. 1357 In this case, \np{ln \_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined.1352 In this case, \np{ln_nc4zip}{ln\_nc4zip} is set false and dummy routines for a few NetCDF4-specific functions are defined. 1358 1353 These functions will not be used but need to be included so that compilation is possible with NetCDF3 libraries. 1359 1354 … … 1389 1384 \end{forlines} 1390 1385 1391 \noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\t t 46x38x1} respectively in1392 the mono-processor case (\ie global domain of {\small\tt 182x149x31}).1393 An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in 1394 table \autoref{tab: NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with1386 \noindent for a standard ORCA2\_LIM configuration gives chunksizes of {\small\texttt 46x38x1} respectively in 1387 the mono-processor case (\ie\ global domain of {\small\texttt 182x149x31}). 1388 An illustration of the potential space savings that NetCDF4 chunking and compression provides is given in 1389 table \autoref{tab:DIA_NC4} which compares the results of two short runs of the ORCA2\_LIM reference configuration with 1395 1390 a 4x2 mpi partitioning. 1396 1391 Note the variation in the compression ratio achieved which reflects chiefly the dry to wet volume ratio of 1397 1392 each processing region. 1398 1393 1399 %------------------------------------------TABLE----------------------------------------------------1400 1394 \begin{table} 1401 \scriptsize1402 1395 \centering 1403 1396 \begin{tabular}{lrrr} … … 1431 1424 ORCA2\_2d\_grid\_W\_0007.nc & 4416 & 1368 & 70\% \\ 1432 1425 \end{tabular} 1433 \caption{ 1434 \protect\label{tab:NC4} 1435 Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression 1436 } 1426 \caption{Filesize comparison between NetCDF3 and NetCDF4 with chunking and compression} 1427 \label{tab:DIA_NC4} 1437 1428 \end{table} 1438 %----------------------------------------------------------------------------------------------------1439 1429 1440 1430 When \key{iomput} is activated with \key{netcdf4} chunking and compression parameters for fields produced via 1441 \ np{iom\_put} calls are set via an equivalent and identically named namelist to \textit{namnc4} in1442 \ np{xmlio\_server.def}.1443 Typically this namelist serves the mean files whilst the \n gn{ namnc4} in the main namelist file continues to1431 \rou{iom\_put} calls are set via an equivalent and identically named namelist to \nam{nc4}{nc4} in 1432 \textit{xmlio\_server.def}. 1433 Typically this namelist serves the mean files whilst the \nam{nc4}{nc4} in the main namelist file continues to 1444 1434 serve the restart files. 1445 1435 This duplication is unfortunate but appropriate since, if using io\_servers, the domain sizes of 1446 1436 the individual files produced by the io\_server processes may be different to those produced by 1447 1437 the invidual processing regions and different chunking choices may be desired. 1448 1449 % ------------------------------------------------------------------------------------------------------------- 1450 % Tracer/Dynamics Trends 1451 % ------------------------------------------------------------------------------------------------------------- 1452 \section{Tracer/Dynamics trends (\protect\ngn{namtrd})} 1438 1439 %% ================================================================================================= 1440 \section[Tracer/Dynamics trends (\forcode{&namtrd})]{Tracer/Dynamics trends (\protect\nam{trd}{trd})} 1453 1441 \label{sec:DIA_trd} 1454 1442 1455 %------------------------------------------namtrd---------------------------------------------------- 1456 1457 \nlst{namtrd} 1458 %------------------------------------------------------------------------------------------------------------- 1443 \begin{listing} 1444 \nlst{namtrd} 1445 \caption{\forcode{&namtrd}} 1446 \label{lst:namtrd} 1447 \end{listing} 1459 1448 1460 1449 Each trend of the dynamics and/or temperature and salinity time evolution equations can be send to 1461 1450 \mdl{trddyn} and/or \mdl{trdtra} modules (see TRD directory) just after their computation 1462 (\ie at the end of each $dyn\cdots.F90$ and/or $tra\cdots.F90$routines).1463 This capability is controlled by options offered in \n gn{namtrd} namelist.1464 Note that the output are done with xIOS, and therefore the \key{IOM} is required.1465 1466 What is done depends on the \n gn{namtrd} logical set to \forcode{.true.}:1451 (\ie\ at the end of each \textit{dyn....F90} and/or \textit{tra....F90} routines). 1452 This capability is controlled by options offered in \nam{trd}{trd} namelist. 1453 Note that the output are done with XIOS, and therefore the \key{iomput} is required. 1454 1455 What is done depends on the \nam{trd}{trd} logical set to \forcode{.true.}: 1467 1456 1468 1457 \begin{description} 1469 \item[\np{ln\_glo\_trd}]: 1470 at each \np{nn\_trd} time-step a check of the basin averaged properties of 1458 \item [{\np{ln_glo_trd}{ln\_glo\_trd}}]: at each \np{nn_trd}{nn\_trd} time-step a check of the basin averaged properties of 1471 1459 the momentum and tracer equations is performed. 1472 1460 This also includes a check of $T^2$, $S^2$, $\tfrac{1}{2} (u^2+v2)$, 1473 1461 and potential energy time evolution equations properties; 1474 \item[\np{ln\_dyn\_trd}]: 1475 each 3D trend of the evolution of the two momentum components is output; 1476 \item[\np{ln\_dyn\_mxl}]: 1477 each 3D trend of the evolution of the two momentum components averaged over the mixed layer is output; 1478 \item[\np{ln\_vor\_trd}]: 1479 a vertical summation of the moment tendencies is performed, 1462 \item [{\np{ln_dyn_trd}{ln\_dyn\_trd}}]: each 3D trend of the evolution of the two momentum components is output; 1463 \item [{\np{ln_dyn_mxl}{ln\_dyn\_mxl}}]: each 3D trend of the evolution of the two momentum components averaged over the mixed layer is output; 1464 \item [{\np{ln_vor_trd}{ln\_vor\_trd}}]: a vertical summation of the moment tendencies is performed, 1480 1465 then the curl is computed to obtain the barotropic vorticity tendencies which are output; 1481 \item[\np{ln\_KE\_trd}] : 1482 each 3D trend of the Kinetic Energy equation is output; 1483 \item[\np{ln\_tra\_trd}]: 1484 each 3D trend of the evolution of temperature and salinity is output; 1485 \item[\np{ln\_tra\_mxl}]: 1486 each 2D trend of the evolution of temperature and salinity averaged over the mixed layer is output; 1466 \item [{\np{ln_KE_trd}{ln\_KE\_trd}}] : each 3D trend of the Kinetic Energy equation is output; 1467 \item [{\np{ln_tra_trd}{ln\_tra\_trd}}]: each 3D trend of the evolution of temperature and salinity is output; 1468 \item [{\np{ln_tra_mxl}{ln\_tra\_mxl}}]: each 2D trend of the evolution of temperature and salinity averaged over the mixed layer is output; 1487 1469 \end{description} 1488 1470 1489 Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via 1490 the \key{trdtrc} and \key{trdm ld\_trc} CPP keys.1471 Note that the mixed layer tendency diagnostic can also be used on biogeochemical models via 1472 the \key{trdtrc} and \key{trdmxl\_trc} CPP keys. 1491 1473 1492 1474 \textbf{Note that} in the current version (v3.6), many changes has been introduced but not fully tested. 1493 In particular, options associated with \np{ln \_dyn\_mxl}, \np{ln\_vor\_trd}, and \np{ln\_tra\_mxl} are not working,1494 and none of the options have been tested with variable volume (\ie \key{vvl} defined).1495 1496 % -------------------------------------------------------------------------------------------------------------1497 % On-line Floats trajectories 1498 % ------------------------------------------------------------------------------------------------------------- 1499 \section{FLO: On-Line Floats trajectories (\protect\key{floats})} 1500 \ label{sec:FLO}1501 %--------------------------------------------namflo------------------------------------------------------- 1502 1503 \nlst{namflo} 1504 %-------------------------------------------------------------------------------------------------------------- 1475 In particular, options associated with \np{ln_dyn_mxl}{ln\_dyn\_mxl}, \np{ln_vor_trd}{ln\_vor\_trd}, and \np{ln_tra_mxl}{ln\_tra\_mxl} are not working, 1476 and none of the options have been tested with variable volume (\ie\ \np[=.true.]{ln_linssh}{ln\_linssh}). 1477 1478 %% ================================================================================================= 1479 \section[FLO: On-Line Floats trajectories (\texttt{\textbf{key\_floats}})]{FLO: On-Line Floats trajectories (\protect\key{floats})} 1480 \label{sec:DIA_FLO} 1481 1482 \begin{listing} 1483 \nlst{namflo} 1484 \caption{\forcode{&namflo}} 1485 \label{lst:namflo} 1486 \end{listing} 1505 1487 1506 1488 The on-line computation of floats advected either by the three dimensional velocity field or constraint to 1507 1489 remain at a given depth ($w = 0$ in the computation) have been introduced in the system during the CLIPPER project. 1508 Options are defined by \n gn{namflo} namelisvariables.1509 The algorithm used is based either on the work of \cite{ Blanke_Raynaud_JPO97} (default option),1510 or on a $4^th$ Runge-Hutta algorithm (\np {ln\_flork4}\forcode{ = .true.}).1511 Note that the \cite{ Blanke_Raynaud_JPO97} algorithm have the advantage of providing trajectories which1490 Options are defined by \nam{flo}{flo} namelist variables. 1491 The algorithm used is based either on the work of \cite{blanke.raynaud_JPO97} (default option), 1492 or on a $4^th$ Runge-Hutta algorithm (\np[=.true.]{ln_flork4}{ln\_flork4}). 1493 Note that the \cite{blanke.raynaud_JPO97} algorithm have the advantage of providing trajectories which 1512 1494 are consistent with the numeric of the code, so that the trajectories never intercept the bathymetry. 1513 1495 1496 %% ================================================================================================= 1514 1497 \subsubsection{Input data: initial coordinates} 1515 1498 1516 1499 Initial coordinates can be given with Ariane Tools convention 1517 (IJK coordinates, (\np {ln\_ariane}\forcode{ = .true.}) ) or with longitude and latitude.1518 1519 In case of Ariane convention, input filename is \ np{init\_float\_ariane}.1500 (IJK coordinates, (\np[=.true.]{ln_ariane}{ln\_ariane}) ) or with longitude and latitude. 1501 1502 In case of Ariane convention, input filename is \textit{init\_float\_ariane}. 1520 1503 Its format is: \\ 1521 { \scriptsize \texttt{I J K nisobfl itrashitrash}}1504 { \texttt{I J K nisobfl itrash}} 1522 1505 1523 1506 \noindent with: … … 1525 1508 - I,J,K : indexes of initial position 1526 1509 1527 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity 1510 - nisobfl: 0 for an isobar float, 1 for a float following the w velocity 1528 1511 1529 1512 - itrash : set to zero; it is a dummy variable to respect Ariane Tools convention … … 1531 1514 \noindent Example: \\ 1532 1515 \noindent 1533 { \scriptsize1516 { 1534 1517 \texttt{ 1535 1518 100.00000 90.00000 -1.50000 1.00000 0.00000 \\ … … 1542 1525 In the other case (longitude and latitude), input filename is init\_float. 1543 1526 Its format is: \\ 1544 { \scriptsize\texttt{Long Lat depth nisobfl ngrpfl itrash}}1527 { \texttt{Long Lat depth nisobfl ngrpfl itrash}} 1545 1528 1546 1529 \noindent with: … … 1556 1539 \noindent Example: \\ 1557 1540 \noindent 1558 { \scriptsize1541 { 1559 1542 \texttt{ 1560 1543 20.0 0.0 0.0 0 1 1 \\ … … 1565 1548 } \\ 1566 1549 1567 \np{jpnfl} is the total number of floats during the run. 1568 When initial positions are read in a restart file (\np{ln\_rstflo}\forcode{ = .true.} ), 1569 \np{jpnflnewflo} can be added in the initialization file. 1570 1550 \np{jpnfl}{jpnfl} is the total number of floats during the run. 1551 When initial positions are read in a restart file (\np[=.true.]{ln_rstflo}{ln\_rstflo} ), 1552 \np{jpnflnewflo}{jpnflnewflo} can be added in the initialization file. 1553 1554 %% ================================================================================================= 1571 1555 \subsubsection{Output data} 1572 1556 1573 \np{nn \_writefl} is the frequency of writing in float output file and \np{nn\_stockfl} is the frequency of1557 \np{nn_writefl}{nn\_writefl} is the frequency of writing in float output file and \np{nn_stockfl}{nn\_stockfl} is the frequency of 1574 1558 creation of the float restart file. 1575 1559 1576 Output data can be written in ascii files (\np {ln\_flo\_ascii}\forcode{ = .true.}).1560 Output data can be written in ascii files (\np[=.true.]{ln_flo_ascii}{ln\_flo\_ascii}). 1577 1561 In that case, output filename is trajec\_float. 1578 1562 1579 Another possiblity of writing format is Netcdf (\np{ln\_flo\_ascii}\forcode{ = .false.}). 1580 There are 2 possibilities: 1581 1582 - if (\key{iomput}) is used, outputs are selected in iodef.xml. 1563 Another possiblity of writing format is Netcdf (\np[=.false.]{ln_flo_ascii}{ln\_flo\_ascii}) with 1564 \key{iomput} and outputs selected in iodef.xml. 1583 1565 Here it is an example of specification to put in files description section: 1584 1566 … … 1597 1579 \end{xmllines} 1598 1580 1599 - if (\key{iomput}) is not used, a file called \ifile{trajec\_float} will be created by IOIPSL library. 1600 1601 See also \href{http://stockage.univ-brest.fr/~grima/Ariane/}{here} the web site describing the off-line use of 1602 this marvellous diagnostic tool. 1603 1604 % ------------------------------------------------------------------------------------------------------------- 1605 % Harmonic analysis of tidal constituents 1606 % ------------------------------------------------------------------------------------------------------------- 1607 \section{Harmonic analysis of tidal constituents (\protect\key{diaharm}) } 1581 %% ================================================================================================= 1582 \section[Harmonic analysis of tidal constituents (\texttt{\textbf{key\_diaharm}})]{Harmonic analysis of tidal constituents (\protect\key{diaharm})} 1608 1583 \label{sec:DIA_diag_harm} 1609 1584 1610 %------------------------------------------namdia_harm---------------------------------------------------- 1611 % 1612 \nlst{nam_diaharm} 1613 %---------------------------------------------------------------------------------------------------------- 1585 \begin{listing} 1586 \nlst{nam_diaharm} 1587 \caption{\forcode{&nam_diaharm}} 1588 \label{lst:nam_diaharm} 1589 \end{listing} 1614 1590 1615 1591 A module is available to compute the amplitude and phase of tidal waves. 1616 1592 This on-line Harmonic analysis is actived with \key{diaharm}. 1617 1593 1618 Some parameters are available in namelist \n gn{namdia\_harm}:1619 1620 - \np{nit000 \_han} is the first time step used for harmonic analysis1621 1622 - \np{nitend \_han} is the last time step used for harmonic analysis1623 1624 - \np{nstep \_han} is the time step frequency for harmonic analysis1625 1626 - \np{nb\_ana} is the number of harmonics to analyse1627 1628 - \np{tname} is an array with names of tidal constituents to analyse1629 1630 \np{nit000 \_han} and \np{nitend\_han} must be between \np{nit000} and \np{nitend} of the simulation.1594 Some parameters are available in namelist \nam{_diaharm}{\_diaharm}: 1595 1596 - \np{nit000_han}{nit000\_han} is the first time step used for harmonic analysis 1597 1598 - \np{nitend_han}{nitend\_han} is the last time step used for harmonic analysis 1599 1600 - \np{nstep_han}{nstep\_han} is the time step frequency for harmonic analysis 1601 1602 % - \np{nb_ana}{nb\_ana} is the number of harmonics to analyse 1603 1604 - \np{tname}{tname} is an array with names of tidal constituents to analyse 1605 1606 \np{nit000_han}{nit000\_han} and \np{nitend_han}{nitend\_han} must be between \np{nit000}{nit000} and \np{nitend}{nitend} of the simulation. 1631 1607 The restart capability is not implemented. 1632 1608 … … 1649 1625 We obtain in output $C_{j}$ and $S_{j}$ for each tidal wave. 1650 1626 1651 % ------------------------------------------------------------------------------------------------------------- 1652 % Sections transports 1653 % ------------------------------------------------------------------------------------------------------------- 1654 \section{Transports across sections (\protect\key{diadct}) } 1627 %% ================================================================================================= 1628 \section[Transports across sections (\texttt{\textbf{key\_diadct}})]{Transports across sections (\protect\key{diadct})} 1655 1629 \label{sec:DIA_diag_dct} 1656 1630 1657 %------------------------------------------namdct---------------------------------------------------- 1658 1659 \nlst{namdct} 1660 %------------------------------------------------------------------------------------------------------------- 1631 \begin{listing} 1632 \nlst{nam_diadct} 1633 \caption{\forcode{&nam_diadct}} 1634 \label{lst:nam_diadct} 1635 \end{listing} 1661 1636 1662 1637 A module is available to compute the transport of volume, heat and salt through sections. … … 1664 1639 1665 1640 Each section is defined by the coordinates of its 2 extremities. 1666 The pathways between them are contructed using tools which can be found in \texttt{ NEMOGCM/TOOLS/SECTIONS\_DIADCT}1667 and are written in a binary file \texttt{section\_ijglobal.diadct \_ORCA2\_LIM} which is later read in by1668 NEMOto compute on-line transports.1641 The pathways between them are contructed using tools which can be found in \texttt{tools/SECTIONS\_DIADCT} 1642 and are written in a binary file \texttt{section\_ijglobal.diadct} which is later read in by 1643 \NEMO\ to compute on-line transports. 1669 1644 1670 1645 The on-line transports module creates three output ascii files: … … 1676 1651 - \texttt{salt\_transport} for salt transports (unit: $10^{9}Kg s^{-1}$) \\ 1677 1652 1678 Namelist variables in \n gn{namdct} control how frequently the flows are summed and the time scales over which1653 Namelist variables in \nam{_diadct}{\_diadct} control how frequently the flows are summed and the time scales over which 1679 1654 they are averaged, as well as the level of output for debugging: 1680 \np{nn\_dct} : frequency of instantaneous transports computing 1681 \np{nn\_dctwri}: frequency of writing ( mean of instantaneous transports ) 1682 \np{nn\_debug} : debugging of the section 1683 1655 \np{nn_dct}{nn\_dct} : frequency of instantaneous transports computing 1656 \np{nn_dctwri}{nn\_dctwri}: frequency of writing ( mean of instantaneous transports ) 1657 \np{nn_debug}{nn\_debug} : debugging of the section 1658 1659 %% ================================================================================================= 1684 1660 \subsubsection{Creating a binary file containing the pathway of each section} 1685 1661 1686 In \texttt{ NEMOGCM/TOOLS/SECTIONS\_DIADCT/run},1662 In \texttt{tools/SECTIONS\_DIADCT/run}, 1687 1663 the file \textit{ {list\_sections.ascii\_global}} contains a list of all the sections that are to be computed 1688 1664 (this list of sections is based on MERSEA project metrics). … … 1691 1667 1692 1668 Each section is defined by: \\ 1693 \noindent { \scriptsize\texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}} \\1669 \noindent { \texttt{long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name}} \\ 1694 1670 with: 1695 1671 … … 1698 1674 - \texttt{long2 lat2}, coordinates of the second extremity of the section; 1699 1675 1700 - \texttt{nclass} the number of bounds of your classes (\eg bounds for 2 classes);1676 - \texttt{nclass} the number of bounds of your classes (\eg\ bounds for 2 classes); 1701 1677 1702 1678 - \texttt{okstrpond} to compute heat and salt transports, \texttt{nostrpond} if no; … … 1708 1684 1709 1685 \noindent If nclass $\neq$ 0, the next lines contain the class type and the nclass bounds: \\ 1710 { \scriptsize1686 { 1711 1687 \texttt{ 1712 1688 long1 lat1 long2 lat2 nclass (ok/no)strpond (no)ice section\_name \\ … … 1731 1707 1732 1708 - \texttt{zsigp} for potential density classes \\ 1733 1709 1734 1710 The script \texttt{job.ksh} computes the pathway for each section and creates a binary file 1735 \texttt{section\_ijglobal.diadct \_ORCA2\_LIM} which is read byNEMO. \\1711 \texttt{section\_ijglobal.diadct} which is read by \NEMO. \\ 1736 1712 1737 1713 It is possible to use this tools for new configuations: \texttt{job.ksh} has to be updated with … … 1741 1717 and the ATL\_Cuba\_Florida with 4 temperature clases (5 class bounds), are shown: \\ 1742 1718 \noindent 1743 { \scriptsize1719 { 1744 1720 \texttt{ 1745 1721 -68. -54.5 -60. -64.7 00 okstrpond noice ACC\_Drake\_Passage \\ … … 1753 1729 } 1754 1730 1731 %% ================================================================================================= 1755 1732 \subsubsection{To read the output files} 1756 1733 1757 1734 The output format is: \\ 1758 { \scriptsize1735 { 1759 1736 \texttt{ 1760 1737 date, time-step number, section number, \\ … … 1778 1755 1779 1756 \begin{table} 1780 \scriptsize1781 1757 \begin{tabular}{|l|l|l|l|l|} 1782 1758 \hline … … 1792 1768 \end{table} 1793 1769 1794 % ================================================================ 1795 % Steric effect in sea surface height 1796 % ================================================================ 1770 %% ================================================================================================= 1797 1771 \section{Diagnosing the steric effect in sea surface height} 1798 1772 \label{sec:DIA_steric} 1799 1800 1773 1801 1774 Changes in steric sea level are caused when changes in the density of the water column imply an expansion or … … 1809 1782 The steric effect is therefore not explicitely represented. 1810 1783 This approximation does not represent a serious error with respect to the flow field calculated by the model 1811 \citep{ Greatbatch_JGR94}, but extra attention is required when investigating sea level,1784 \citep{greatbatch_JGR94}, but extra attention is required when investigating sea level, 1812 1785 as steric changes are an important contribution to local changes in sea level on seasonal and climatic time scales. 1813 1786 This is especially true for investigation into sea level rise due to global warming. 1814 1787 1815 1788 Fortunately, the steric contribution to the sea level consists of a spatially uniform component that 1816 can be diagnosed by considering the mass budget of the world ocean \citep{ Greatbatch_JGR94}.1789 can be diagnosed by considering the mass budget of the world ocean \citep{greatbatch_JGR94}. 1817 1790 In order to better understand how global mean sea level evolves and thus how the steric sea level can be diagnosed, 1818 1791 we compare, in the following, the non-Boussinesq and Boussinesq cases. 1819 1792 1820 1793 Let denote 1821 $\mathcal{M}$ the total mass of liquid seawater ($\mathcal{M} = \int_D \rho dv$), 1822 $\mathcal{V}$ the total volume of seawater ($\mathcal{V} = \int_D dv$), 1823 $\mathcal{A}$ the total surface of the ocean ($\mathcal{A} = \int_S ds$), 1824 $\bar{\rho}$ the global mean seawater (\textit{in situ}) density 1794 $\mathcal{M}$ the total mass of liquid seawater ($\mathcal{M} = \int_D \rho dv$), 1795 $\mathcal{V}$ the total volume of seawater ($\mathcal{V} = \int_D dv$), 1796 $\mathcal{A}$ the total surface of the ocean ($\mathcal{A} = \int_S ds$), 1797 $\bar{\rho}$ the global mean seawater (\textit{in situ}) density 1825 1798 ($\bar{\rho} = 1/\mathcal{V} \int_D \rho \,dv$), and 1826 $\bar{\eta}$ the global mean sea level 1799 $\bar{\eta}$ the global mean sea level 1827 1800 ($\bar{\eta} = 1/\mathcal{A} \int_S \eta \,ds$). 1828 1801 … … 1834 1807 \mathcal{V} &= \mathcal{A} \;\bar{\eta} 1835 1808 \end{split} 1836 \label{eq: MV_nBq}1809 \label{eq:DIA_MV_nBq} 1837 1810 \end{equation} 1838 1811 … … 1842 1815 \frac{1}{e_3} \partial_t ( e_3\,\rho) + \nabla( \rho \, \textbf{U} ) 1843 1816 = \left. \frac{\textit{emp}}{e_3}\right|_\textit{surface} 1844 \label{eq: Co_nBq}1817 \label{eq:DIA_Co_nBq} 1845 1818 \end{equation} 1846 1819 1847 1820 where $\rho$ is the \textit{in situ} density, and \textit{emp} the surface mass exchanges with the other media of 1848 1821 the Earth system (atmosphere, sea-ice, land). 1849 Its global averaged leads to the total mass change 1822 Its global averaged leads to the total mass change 1850 1823 1851 1824 \begin{equation} 1852 1825 \partial_t \mathcal{M} = \mathcal{A} \;\overline{\textit{emp}} 1853 \label{eq: Mass_nBq}1826 \label{eq:DIA_Mass_nBq} 1854 1827 \end{equation} 1855 1828 1856 1829 where $\overline{\textit{emp}} = \int_S \textit{emp}\,ds$ is the net mass flux through the ocean surface. 1857 Bringing \autoref{eq: Mass_nBq} and the time derivative of \autoref{eq:MV_nBq} together leads to1830 Bringing \autoref{eq:DIA_Mass_nBq} and the time derivative of \autoref{eq:DIA_MV_nBq} together leads to 1858 1831 the evolution equation of the mean sea level 1859 1832 … … 1861 1834 \partial_t \bar{\eta} = \frac{\overline{\textit{emp}}}{ \bar{\rho}} 1862 1835 - \frac{\mathcal{V}}{\mathcal{A}} \;\frac{\partial_t \bar{\rho} }{\bar{\rho}} 1863 \label{eq: ssh_nBq}1836 \label{eq:DIA_ssh_nBq} 1864 1837 \end{equation} 1865 1838 1866 The first term in equation \autoref{eq: ssh_nBq} alters sea level by adding or subtracting mass from the ocean.1867 The second term arises from temporal changes in the global mean density; \ie from steric effects.1839 The first term in equation \autoref{eq:DIA_ssh_nBq} alters sea level by adding or subtracting mass from the ocean. 1840 The second term arises from temporal changes in the global mean density; \ie\ from steric effects. 1868 1841 1869 1842 In a Boussinesq fluid, $\rho$ is replaced by $\rho_o$ in all the equation except when $\rho$ appears multiplied by 1870 the gravity (\ie in the hydrostatic balance of the primitive Equations).1871 In particular, the mass conservation equation, \autoref{eq: Co_nBq}, degenerates into the incompressibility equation:1843 the gravity (\ie\ in the hydrostatic balance of the primitive Equations). 1844 In particular, the mass conservation equation, \autoref{eq:DIA_Co_nBq}, degenerates into the incompressibility equation: 1872 1845 1873 1846 \[ 1874 1847 \frac{1}{e_3} \partial_t ( e_3 ) + \nabla( \textbf{U} ) = \left. \frac{\textit{emp}}{\rho_o \,e_3}\right|_ \textit{surface} 1875 % \label{eq: Co_Bq}1848 % \label{eq:DIA_Co_Bq} 1876 1849 \] 1877 1850 … … 1880 1853 \[ 1881 1854 \partial_t \mathcal{V} = \mathcal{A} \;\frac{\overline{\textit{emp}}}{\rho_o} 1882 % \label{eq: V_Bq}1855 % \label{eq:DIA_V_Bq} 1883 1856 \] 1884 1857 … … 1888 1861 the ocean surface, not by changes in mean mass of the ocean: the steric effect is missing in a Boussinesq fluid. 1889 1862 1890 Nevertheless, following \citep{ Greatbatch_JGR94}, the steric effect on the volume can be diagnosed by1891 considering the mass budget of the ocean. 1863 Nevertheless, following \citep{greatbatch_JGR94}, the steric effect on the volume can be diagnosed by 1864 considering the mass budget of the ocean. 1892 1865 The apparent changes in $\mathcal{M}$, mass of the ocean, which are not induced by surface mass flux 1893 1866 must be compensated by a spatially uniform change in the mean sea level due to expansion/contraction of the ocean 1894 \citep{ Greatbatch_JGR94}.1867 \citep{greatbatch_JGR94}. 1895 1868 In others words, the Boussinesq mass, $\mathcal{M}_o$, can be related to $\mathcal{M}$, 1896 1869 the total mass of the ocean seen by the Boussinesq model, via the steric contribution to the sea level, … … 1899 1872 \begin{equation} 1900 1873 \mathcal{M}_o = \mathcal{M} + \rho_o \,\eta_s \,\mathcal{A} 1901 \label{eq: M_Bq}1874 \label{eq:DIA_M_Bq} 1902 1875 \end{equation} 1903 1876 … … 1905 1878 is converted into a mean change in sea level. 1906 1879 Introducing the total density anomaly, $\mathcal{D}= \int_D d_a \,dv$, 1907 where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO (cf. \autoref{subsec:TRA_eos})1908 in \autoref{eq: M_Bq} leads to a very simple form for the steric height:1880 where $d_a = (\rho -\rho_o ) / \rho_o$ is the density anomaly used in \NEMO\ (cf. \autoref{subsec:TRA_eos}) 1881 in \autoref{eq:DIA_M_Bq} leads to a very simple form for the steric height: 1909 1882 1910 1883 \begin{equation} 1911 1884 \eta_s = - \frac{1}{\mathcal{A}} \mathcal{D} 1912 \label{eq: steric_Bq}1885 \label{eq:DIA_steric_Bq} 1913 1886 \end{equation} 1914 1887 1915 1888 The above formulation of the steric height of a Boussinesq ocean requires four remarks. 1916 1889 First, one can be tempted to define $\rho_o$ as the initial value of $\mathcal{M}/\mathcal{V}$, 1917 \ie set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero.1890 \ie\ set $\mathcal{D}_{t=0}=0$, so that the initial steric height is zero. 1918 1891 We do not recommend that. 1919 1892 Indeed, in this case $\rho_o$ depends on the initial state of the ocean. … … 1924 1897 This value is a sensible choice for the reference density used in a Boussinesq ocean climate model since, 1925 1898 with the exception of only a small percentage of the ocean, density in the World Ocean varies by no more than 1926 2$\%$ from this value (\cite{ Gill1982}, page 47).1899 2$\%$ from this value (\cite{gill_bk82}, page 47). 1927 1900 1928 1901 Second, we have assumed here that the total ocean surface, $\mathcal{A}$, 1929 1902 does not change when the sea level is changing as it is the case in all global ocean GCMs 1930 1903 (wetting and drying of grid point is not allowed). 1931 1932 Third, the discretisation of \autoref{eq: steric_Bq} depends on the type of free surface which is considered.1933 In the non linear free surface case, \ie \key{vvl} defined, it is given by1904 1905 Third, the discretisation of \autoref{eq:DIA_steric_Bq} depends on the type of free surface which is considered. 1906 In the non linear free surface case, \ie\ \np[=.true.]{ln_linssh}{ln\_linssh}, it is given by 1934 1907 1935 1908 \[ 1936 1909 \eta_s = - \frac{ \sum_{i,\,j,\,k} d_a\; e_{1t} e_{2t} e_{3t} }{ \sum_{i,\,j,\,k} e_{1t} e_{2t} e_{3t} } 1937 % \label{eq: discrete_steric_Bq_nfs}1910 % \label{eq:DIA_discrete_steric_Bq_nfs} 1938 1911 \] 1939 1912 … … 1945 1918 \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 } 1946 1919 { \sum_{i,\,j,\,k} e_{1t}e_{2t}e_{3t} + \sum_{i,\,j} e_{1t}e_{2t} \eta } 1947 % \label{eq: discrete_steric_Bq_fs}1920 % \label{eq:DIA_discrete_steric_Bq_fs} 1948 1921 \] 1949 1922 … … 1954 1927 so that there are no associated ocean currents. 1955 1928 Hence, the dynamically relevant sea level is the effective sea level, 1956 \ie the sea level as if sea ice (and snow) were converted to liquid seawater \citep{Campin_al_OM08}.1957 However, in the current version of \NEMO the sea-ice is levitating above the ocean without mass exchanges between1929 \ie\ the sea level as if sea ice (and snow) were converted to liquid seawater \citep{campin.marshall.ea_OM08}. 1930 However, in the current version of \NEMO\ the sea-ice is levitating above the ocean without mass exchanges between 1958 1931 ice and ocean. 1959 1932 Therefore the model effective sea level is always given by $\eta + \eta_s$, whether or not there is sea ice present. … … 1965 1938 \[ 1966 1939 \eta_s = - \frac{1}{\mathcal{A}} \int_D d_a(T,S_o,p_o) \,dv 1967 % \label{eq: thermosteric_Bq}1940 % \label{eq:DIA_thermosteric_Bq} 1968 1941 \] 1969 1942 1970 1943 where $S_o$ and $p_o$ are the initial salinity and pressure, respectively. 1971 1944 1972 Both steric and thermosteric sea level are computed in \mdl{diaar5} which needs the \key{diaar5} defined to 1973 be called. 1974 1975 % ------------------------------------------------------------------------------------------------------------- 1976 % Other Diagnostics 1977 % ------------------------------------------------------------------------------------------------------------- 1978 \section{Other diagnostics (\protect\key{diahth}, \protect\key{diaar5})} 1945 Both steric and thermosteric sea level are computed in \mdl{diaar5}. 1946 1947 %% ================================================================================================= 1948 \section{Other diagnostics} 1979 1949 \label{sec:DIA_diag_others} 1980 1950 … … 1982 1952 The available ready-to-add diagnostics modules can be found in directory DIA. 1983 1953 1984 \subsection{Depth of various quantities (\protect\mdl{diahth})} 1954 %% ================================================================================================= 1955 \subsection[Depth of various quantities (\textit{diahth.F90})]{Depth of various quantities (\protect\mdl{diahth})} 1985 1956 1986 1957 Among the available diagnostics the following ones are obtained when defining the \key{diahth} CPP key: 1987 1958 1988 - the mixed layer depth (based on a density criterion \citep{de _Boyer_Montegut_al_JGR04}) (\mdl{diahth})1959 - the mixed layer depth (based on a density criterion \citep{de-boyer-montegut.madec.ea_JGR04}) (\mdl{diahth}) 1989 1960 1990 1961 - the turbocline depth (based on a turbulent mixing coefficient criterion) (\mdl{diahth}) … … 1994 1965 - the depth of the thermocline (maximum of the vertical temperature gradient) (\mdl{diahth}) 1995 1966 1996 % ----------------------------------------------------------- 1997 % Poleward heat and salt transports 1998 % ----------------------------------------------------------- 1999 2000 \subsection{Poleward heat and salt transports (\protect\mdl{diaptr})} 2001 2002 %------------------------------------------namptr----------------------------------------- 2003 2004 \nlst{namptr} 2005 %----------------------------------------------------------------------------------------- 2006 2007 The poleward heat and salt transports, their advective and diffusive component, 2008 and the meriodional stream function can be computed on-line in \mdl{diaptr} \np{ln\_diaptr} to true 2009 (see the \textit{\ngn{namptr} } namelist below). 2010 When \np{ln\_subbas}\forcode{ = .true.}, transports and stream function are computed for the Atlantic, Indian, 1967 \begin{figure}[!t] 1968 \centering 1969 \includegraphics[width=0.66\textwidth]{DIA_mask_subasins} 1970 \caption[Decomposition of the World Ocean to compute transports as well as 1971 the meridional stream-function]{ 1972 Decomposition of the World Ocean (here ORCA2) into sub-basin used in to 1973 compute the heat and salt transports as well as the meridional stream-function: 1974 Atlantic basin (red), Pacific basin (green), 1975 Indian basin (blue), Indo-Pacific basin (blue+green). 1976 Note that semi-enclosed seas (Red, Med and Baltic seas) as well as 1977 Hudson Bay are removed from the sub-basins. 1978 Note also that the Arctic Ocean has been split into Atlantic and 1979 Pacific basins along the North fold line. 1980 } 1981 \label{fig:DIA_mask_subasins} 1982 \end{figure} 1983 1984 %% ================================================================================================= 1985 \subsection[CMIP specific diagnostics (\textit{diaar5.F90}, \textit{diaptr.F90})]{CMIP specific diagnostics (\protect\mdl{diaar5})} 1986 1987 A series of diagnostics has been added in the \mdl{diaar5} and \mdl{diaptr}. 1988 In \mdl{diaar5} they correspond to outputs that are required for AR5 simulations (CMIP5) 1989 (see also \autoref{sec:DIA_steric} for one of them). 1990 The module \mdl{diaar5} is active when one of the following outputs is required : 1991 global total volume (voltot), global mean ssh (sshtot), global total mass (masstot), global mean temperature (temptot), 1992 global mean ssh steric (sshsteric), global mean ssh thermosteric (sshthster), global mean salinity (saltot), 1993 sea water pressure at sea floor (botpres), dynamic sea surface height (sshdyn). 1994 1995 In \mdl{diaptr} when \np[=.true.]{ln_diaptr}{ln\_diaptr} 1996 (see the \nam{ptr}{ptr} namelist below) can be computed on-line the poleward heat and salt transports, 1997 their advective and diffusive component, and the meriodional stream function . 1998 When \np[=.true.]{ln_subbas}{ln\_subbas}, transports and stream function are computed for the Atlantic, Indian, 2011 1999 Pacific and Indo-Pacific Oceans (defined north of 30\deg{S}) as well as for the World Ocean. 2012 2000 The sub-basin decomposition requires an input file (\ifile{subbasins}) which contains three 2D mask arrays, 2013 the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:mask_subasins}). 2014 2015 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016 \begin{figure}[!t] 2017 \begin{center} 2018 \includegraphics[width=1.0\textwidth]{Fig_mask_subasins} 2019 \caption{ 2020 \protect\label{fig:mask_subasins} 2021 Decomposition of the World Ocean (here ORCA2) into sub-basin used in to 2022 compute the heat and salt transports as well as the meridional stream-function: 2023 Atlantic basin (red), Pacific basin (green), Indian basin (bleue), Indo-Pacific basin (bleue+green). 2024 Note that semi-enclosed seas (Red, Med and Baltic seas) as well as Hudson Bay are removed from the sub-basins. 2025 Note also that the Arctic Ocean has been split into Atlantic and Pacific basins along the North fold line. 2026 } 2027 \end{center} 2028 \end{figure} 2029 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2030 2031 % ----------------------------------------------------------- 2032 % CMIP specific diagnostics 2033 % ----------------------------------------------------------- 2034 \subsection{CMIP specific diagnostics (\protect\mdl{diaar5})} 2035 2036 A series of diagnostics has been added in the \mdl{diaar5}. 2037 They corresponds to outputs that are required for AR5 simulations (CMIP5) 2038 (see also \autoref{sec:DIA_steric} for one of them). 2039 Activating those outputs requires to define the \key{diaar5} CPP key. 2040 2041 % ----------------------------------------------------------- 2042 % 25 hour mean and hourly Surface, Mid and Bed 2043 % ----------------------------------------------------------- 2001 the Indo-Pacific mask been deduced from the sum of the Indian and Pacific mask (\autoref{fig:DIA_mask_subasins}). 2002 2003 \begin{listing} 2004 \nlst{namptr} 2005 \caption{\forcode{&namptr}} 2006 \label{lst:namptr} 2007 \end{listing} 2008 2009 %% ================================================================================================= 2044 2010 \subsection{25 hour mean output for tidal models} 2045 2011 2046 %------------------------------------------nam_dia25h------------------------------------- 2047 2048 \nlst{nam_dia25h} 2049 %----------------------------------------------------------------------------------------- 2012 \begin{listing} 2013 \nlst{nam_dia25h} 2014 \caption{\forcode{&nam_dia25h}} 2015 \label{lst:nam_dia25h} 2016 \end{listing} 2050 2017 2051 2018 A module is available to compute a crudely detided M2 signal by obtaining a 25 hour mean. … … 2054 2021 This diagnostic is actived with the logical $ln\_dia25h$. 2055 2022 2056 % ----------------------------------------------------------- 2057 % Top Middle and Bed hourly output 2058 % ----------------------------------------------------------- 2023 %% ================================================================================================= 2059 2024 \subsection{Top middle and bed hourly output} 2060 2025 2061 %------------------------------------------nam_diatmb----------------------------------------------------- 2062 2063 \nlst{nam_diatmb} 2064 %---------------------------------------------------------------------------------------------------------- 2026 \begin{listing} 2027 \nlst{nam_diatmb} 2028 \caption{\forcode{&nam_diatmb}} 2029 \label{lst:nam_diatmb} 2030 \end{listing} 2065 2031 2066 2032 A module is available to output the surface (top), mid water and bed diagnostics of a set of standard variables. … … 2070 2036 This diagnostic is actived with the logical $ln\_diatmb$. 2071 2037 2072 % ----------------------------------------------------------- 2073 % Courant numbers 2074 % ----------------------------------------------------------- 2038 %% ================================================================================================= 2075 2039 \subsection{Courant numbers} 2076 2040 … … 2080 2044 \[ 2081 2045 C_u = |u|\frac{\rdt}{e_{1u}}, \quad C_v = |v|\frac{\rdt}{e_{2v}}, \quad C_w = |w|\frac{\rdt}{e_{3w}} 2082 % \label{eq: CFL}2046 % \label{eq:DIA_CFL} 2083 2047 \] 2084 2048 … … 2089 2053 Values greater than 1 indicate that information is propagated across more than one grid cell in a single time step. 2090 2054 2091 The variables can be activated by setting the \np{nn \_diacfl} namelist parameter to 1 in the \ngn{namctl} namelist.2055 The variables can be activated by setting the \np{nn_diacfl}{nn\_diacfl} namelist parameter to 1 in the \nam{ctl}{ctl} namelist. 2092 2056 The diagnostics will be written out to an ascii file named cfl\_diagnostics.ascii. 2093 2057 In this file the maximum value of $C_u$, $C_v$, and $C_w$ are printed at each timestep along with the coordinates of … … 2095 2059 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 2096 2060 with the coordinates of each. 2097 The maximum values from the run are also copied to the ocean.output file. 2098 2099 % ================================================================ 2100 2101 \biblio 2102 2103 \pindex 2061 The maximum values from the run are also copied to the ocean.output file. 2062 2063 \subinc{\input{../../global/epilogue}} 2104 2064 2105 2065 \end{document} -
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DIU.tex
r10442 r11830 2 2 3 3 \begin{document} 4 % ================================================================ 5 % Diurnal SST models (DIU) 6 % Edited by James While 7 % ================================================================ 4 8 5 \chapter{Diurnal SST Models (DIU)} 9 6 \label{chap:DIU} 10 7 11 \ minitoc8 \thispagestyle{plain} 12 9 10 \chaptertoc 13 11 14 \newpage 15 $\ $\newline % force a new line 12 \paragraph{Changes record} ~\\ 13 14 {\footnotesize 15 \begin{tabularx}{\textwidth}{l||X|X} 16 Release & Author(s) & Modifications \\ 17 \hline 18 {\em 4.0} & {\em ...} & {\em ...} \\ 19 {\em 3.6} & {\em ...} & {\em ...} \\ 20 {\em 3.4} & {\em ...} & {\em ...} \\ 21 {\em <=3.4} & {\em ...} & {\em ...} 22 \end{tabularx} 23 } 24 25 \clearpage 16 26 17 27 Code to produce an estimate of the diurnal warming and cooling of the sea surface skin 18 temperature (skin SST) is found in the DIU directory. 28 temperature (skin SST) is found in the DIU directory. 19 29 The skin temperature can be split into three parts: 20 30 \begin{itemize} 21 \item 22 A foundation SST which is free from diurnal warming. 23 \item 24 A warm layer, typically ~3\,m thick, 31 \item A foundation SST which is free from diurnal warming. 32 \item A warm layer, typically ~3\,m thick, 25 33 where heating from solar radiation can cause a warm stably stratified layer during the daytime 26 \item 27 A cool skin, a thin layer, approximately ~1\, mm thick, 34 \item A cool skin, a thin layer, approximately ~1\, mm thick, 28 35 where long wave cooling is dominant and cools the immediate ocean surface. 29 36 \end{itemize} 30 37 31 38 Models are provided for both the warm layer, \mdl{diurnal\_bulk}, and the cool skin, \mdl{cool\_skin}. 32 Foundation SST is not considered as it can be obtained either from the main NEMOmodel33 (\ie from the temperature of the top few model levels) or from some other source.39 Foundation SST is not considered as it can be obtained either from the main \NEMO\ model 40 (\ie\ from the temperature of the top few model levels) or from some other source. 34 41 It must be noted that both the cool skin and warm layer models produce estimates of the change in temperature 35 ($\Delta T_{\ rm{cs}}$ and $\Delta T_{\rm{wl}}$) and42 ($\Delta T_{\mathrm{cs}}$ and $\Delta T_{\mathrm{wl}}$) and 36 43 both must be added to a foundation SST to obtain the true skin temperature. 37 44 38 Both the cool skin and warm layer models are controlled through the namelist \n gn{namdiu}:45 Both the cool skin and warm layer models are controlled through the namelist \nam{diu}{diu}: 39 46 40 \nlst{namdiu} 47 \begin{listing} 48 \nlst{namdiu} 49 \caption{\forcode{&namdiu}} 50 \label{lst:namdiu} 51 \end{listing} 52 41 53 This namelist contains only two variables: 42 54 \begin{description} 43 \item[\np{ln\_diurnal}] 44 A logical switch for turning on/off both the cool skin and warm layer. 45 \item[\np{ln\_diurnal\_only}] 46 A logical switch which if \forcode{.true.} will run the diurnal model without the other dynamical parts of NEMO. 47 \np{ln\_diurnal\_only} must be \forcode{.false.} if \np{ln\_diurnal} is \forcode{.false.}. 55 \item [{\np{ln_diurnal}{ln\_diurnal}}] A logical switch for turning on/off both the cool skin and warm layer. 56 \item [{\np{ln_diurnal_only}{ln\_diurnal\_only}}] A logical switch which if \forcode{.true.} will run the diurnal model without the other dynamical parts of \NEMO. 57 \np{ln_diurnal_only}{ln\_diurnal\_only} must be \forcode{.false.} if \np{ln_diurnal}{ln\_diurnal} is \forcode{.false.}. 48 58 \end{description} 49 59 … … 53 63 Initialisation is through the restart file. 54 64 Specifically the code will expect the presence of the 2-D variable ``Dsst'' to initialise the warm layer. 55 The cool skin model, which is determined purely by the instantaneous fluxes, has no initialisation variable. 65 The cool skin model, which is determined purely by the instantaneous fluxes, has no initialisation variable. 56 66 57 % ===============================================================67 %% ================================================================================================= 58 68 \section{Warm layer model} 59 \label{sec:warm_layer_sec} 60 %=============================================================== 69 \label{sec:DIU_warm_layer_sec} 61 70 62 The warm layer is calculated using the model of \citet{ Takaya_al_JGR10} (TAKAYA10 model hereafter).71 The warm layer is calculated using the model of \citet{takaya.bidlot.ea_JGR10} (TAKAYA10 model hereafter). 63 72 This is a simple flux based model that is defined by the equations 64 73 \begin{align} 65 \frac{\partial{\Delta T_{\ rm{wl}}}}{\partial{t}}&=&\frac{Q(\nu+1)}{D_T\rho_w c_p74 \frac{\partial{\Delta T_{\mathrm{wl}}}}{\partial{t}}&=&\frac{Q(\nu+1)}{D_T\rho_w c_p 66 75 \nu}-\frac{(\nu+1)ku^*_{w}f(L_a)\Delta T}{D_T\Phi\!\left(\frac{D_T}{L}\right)} \mbox{,} 67 \label{eq: ecmwf1} \\68 L&=&\frac{\rho_w c_p u^{*^3}_{w}}{\kappa g \alpha_w Q }\mbox{,}\label{eq: ecmwf2}76 \label{eq:DIU_ecmwf1} \\ 77 L&=&\frac{\rho_w c_p u^{*^3}_{w}}{\kappa g \alpha_w Q }\mbox{,}\label{eq:DIU_ecmwf2} 69 78 \end{align} 70 where $\Delta T_{\ rm{wl}}$ is the temperature difference between the top of the warm layer and the depth $D_T=3$\,m at which there is assumed to be no diurnal signal.71 In equation (\autoref{eq: ecmwf1}) $\alpha_w=2\times10^{-4}$ is the thermal expansion coefficient of water,79 where $\Delta T_{\mathrm{wl}}$ is the temperature difference between the top of the warm layer and the depth $D_T=3$\,m at which there is assumed to be no diurnal signal. 80 In equation (\autoref{eq:DIU_ecmwf1}) $\alpha_w=2\times10^{-4}$ is the thermal expansion coefficient of water, 72 81 $\kappa=0.4$ is von K\'{a}rm\'{a}n's constant, $c_p$ is the heat capacity at constant pressure of sea water, 73 82 $\rho_w$ is the water density, and $L$ is the Monin-Obukhov length. 74 83 The tunable variable $\nu$ is a shape parameter that defines the expected subskin temperature profile via 75 $T(z) = T(0) - \left( \frac{z}{D_T} \right)^\nu \Delta T_{\ rm{wl}}$,84 $T(z) = T(0) - \left( \frac{z}{D_T} \right)^\nu \Delta T_{\mathrm{wl}}$, 76 85 where $T$ is the absolute temperature and $z\le D_T$ is the depth below the top of the warm layer. 77 86 The influence of wind on TAKAYA10 comes through the magnitude of the friction velocity of the water $u^*_{w}$, … … 79 88 the relationship $u^*_{w} = u_{10}\sqrt{\frac{C_d\rho_a}{\rho_w}}$, where $C_d$ is the drag coefficient, 80 89 and $\rho_a$ is the density of air. 81 The symbol $Q$ in equation (\autoref{eq: ecmwf1}) is the instantaneous total thermal energy flux into90 The symbol $Q$ in equation (\autoref{eq:DIU_ecmwf1}) is the instantaneous total thermal energy flux into 82 91 the diurnal layer, \ie 83 92 \[ 84 Q = Q_{\ rm{sol}} + Q_{\rm{lw}} + Q_{\rm{h}}\mbox{,}85 % \label{eq: e_flux_eqn}93 Q = Q_{\mathrm{sol}} + Q_{\mathrm{lw}} + Q_{\mathrm{h}}\mbox{,} 94 % \label{eq:DIU_e_flux_eqn} 86 95 \] 87 where $Q_{\ rm{h}}$ is the sensible and latent heat flux, $Q_{\rm{lw}}$ is the long wave flux,88 and $Q_{\ rm{sol}}$ is the solar flux absorbed within the diurnal warm layer.89 For $Q_{\ rm{sol}}$ the 9 term representation of \citet{Gentemann_al_JGR09} is used.90 In equation \autoref{eq: ecmwf1} the function $f(L_a)=\max(1,L_a^{\frac{2}{3}})$,96 where $Q_{\mathrm{h}}$ is the sensible and latent heat flux, $Q_{\mathrm{lw}}$ is the long wave flux, 97 and $Q_{\mathrm{sol}}$ is the solar flux absorbed within the diurnal warm layer. 98 For $Q_{\mathrm{sol}}$ the 9 term representation of \citet{gentemann.minnett.ea_JGR09} is used. 99 In equation \autoref{eq:DIU_ecmwf1} the function $f(L_a)=\max(1,L_a^{\frac{2}{3}})$, 91 100 where $L_a=0.3$\footnote{ 92 101 This is a global average value, more accurately $L_a$ could be computed as $L_a=(u^*_{w}/u_s)^{\frac{1}{2}}$, … … 99 108 4\zeta^2}{1+3\zeta+0.25\zeta^2} &(\zeta \ge 0) \\ 100 109 (1 - 16\zeta)^{-\frac{1}{2}} & (\zeta < 0) \mbox{,} 101 \end{array} \right. \label{eq: stab_func_eqn}110 \end{array} \right. \label{eq:DIU_stab_func_eqn} 102 111 \end{equation} 103 where $\zeta=\frac{D_T}{L}$. It is clear that the first derivative of (\autoref{eq: stab_func_eqn}),104 and thus of (\autoref{eq: ecmwf1}), is discontinuous at $\zeta=0$ (\ie$Q\rightarrow0$ in105 equation (\autoref{eq: ecmwf2})).112 where $\zeta=\frac{D_T}{L}$. It is clear that the first derivative of (\autoref{eq:DIU_stab_func_eqn}), 113 and thus of (\autoref{eq:DIU_ecmwf1}), is discontinuous at $\zeta=0$ (\ie\ $Q\rightarrow0$ in 114 equation (\autoref{eq:DIU_ecmwf2})). 106 115 107 The two terms on the right hand side of (\autoref{eq: ecmwf1}) represent different processes.116 The two terms on the right hand side of (\autoref{eq:DIU_ecmwf1}) represent different processes. 108 117 The first term is simply the diabatic heating or cooling of the diurnal warm layer due to 109 118 thermal energy fluxes into and out of the layer. … … 111 120 In practice the second term acts as a relaxation on the temperature. 112 121 113 %=============================================================== 122 %% ================================================================================================= 123 \section{Cool skin model} 124 \label{sec:DIU_cool_skin_sec} 114 125 115 \section{Cool skin model} 116 \label{sec:cool_skin_sec} 117 118 %=============================================================== 119 120 The cool skin is modelled using the framework of \citet{Saunders_JAS82} who used a formulation of the near surface temperature difference based upon the heat flux and the friction velocity $u^*_{w}$. 121 As the cool skin is so thin (~1\,mm) we ignore the solar flux component to the heat flux and the Saunders equation for the cool skin temperature difference $\Delta T_{\rm{cs}}$ becomes 126 The cool skin is modelled using the framework of \citet{saunders_JAS67} who used a formulation of the near surface temperature difference based upon the heat flux and the friction velocity $u^*_{w}$. 127 As the cool skin is so thin (~1\,mm) we ignore the solar flux component to the heat flux and the Saunders equation for the cool skin temperature difference $\Delta T_{\mathrm{cs}}$ becomes 122 128 \[ 123 % \label{eq: sunders_eqn}124 \Delta T_{\ rm{cs}}=\frac{Q_{\rm{ns}}\delta}{k_t} \mbox{,}129 % \label{eq:DIU_sunders_eqn} 130 \Delta T_{\mathrm{cs}}=\frac{Q_{\mathrm{ns}}\delta}{k_t} \mbox{,} 125 131 \] 126 where $Q_{\ rm{ns}}$ is the, usually negative, non-solar heat flux into the ocean and132 where $Q_{\mathrm{ns}}$ is the, usually negative, non-solar heat flux into the ocean and 127 133 $k_t$ is the thermal conductivity of sea water. 128 134 $\delta$ is the thickness of the skin layer and is given by 129 135 \begin{equation} 130 \label{eq: sunders_thick_eqn}136 \label{eq:DIU_sunders_thick_eqn} 131 137 \delta=\frac{\lambda \mu}{u^*_{w}} \mbox{,} 132 138 \end{equation} 133 139 where $\mu$ is the kinematic viscosity of sea water and $\lambda$ is a constant of proportionality which 134 \citet{ Saunders_JAS82} suggested varied between 5 and 10.140 \citet{saunders_JAS67} suggested varied between 5 and 10. 135 141 136 The value of $\lambda$ used in equation (\autoref{eq: sunders_thick_eqn}) is that of \citet{Artale_al_JGR02},137 which is shown in \citet{ Tu_Tsuang_GRL05} to outperform a number of other parametrisations at142 The value of $\lambda$ used in equation (\autoref{eq:DIU_sunders_thick_eqn}) is that of \citet{artale.iudicone.ea_JGR02}, 143 which is shown in \citet{tu.tsuang_GRL05} to outperform a number of other parametrisations at 138 144 both low and high wind speeds. 139 145 Specifically, 140 146 \[ 141 % \label{eq: artale_lambda_eqn}147 % \label{eq:DIU_artale_lambda_eqn} 142 148 \lambda = \frac{ 8.64\times10^4 u^*_{w} k_t }{ \rho c_p h \mu \gamma }\mbox{,} 143 149 \] … … 145 151 $\gamma$ is a dimensionless function of wind speed $u$: 146 152 \[ 147 % \label{eq: artale_gamma_eqn}153 % \label{eq:DIU_artale_gamma_eqn} 148 154 \gamma = 149 155 \begin{cases} … … 154 160 \] 155 161 156 \biblio 157 158 \pindex 162 \subinc{\input{../../global/epilogue}} 159 163 160 164 \end{document} -
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DOM.tex
r10502 r11830 2 2 3 3 \begin{document} 4 % ================================================================ 5 % Chapter 2 ——— Space and Time Domain (DOM) 6 % ================================================================ 4 7 5 \chapter{Space Domain (DOM)} 8 6 \label{chap:DOM} 9 7 10 \minitoc 11 12 % Missing things: 13 % - istate: description of the initial state ==> this has to be put elsewhere.. 14 % perhaps in MISC ? By the way the initialisation of T S and dynamics 15 % should be put outside of DOM routine (better with TRC staff and off-line 16 % tracers) 17 % -geo2ocean: how to switch from geographic to mesh coordinate 18 % - domclo: closed sea and lakes.... management of closea sea area : specific to global configuration, both forced and coupled 19 20 \newpage 21 22 Having defined the continuous equations in \autoref{chap:PE} and chosen a time discretization \autoref{chap:STP}, 23 we need to choose a discretization on a grid, and numerical algorithms. 8 % Missing things 9 % - istate: description of the initial state ==> this has to be put elsewhere.. 10 % perhaps in MISC ? By the way the initialisation of T S and dynamics 11 % should be put outside of DOM routine (better with TRC staff and off-line 12 % tracers) 13 % - geo2ocean: how to switch from geographic to mesh coordinate 14 % - domclo: closed sea and lakes.... 15 % management of closea sea area: specific to global cfg, both forced and coupled 16 17 \thispagestyle{plain} 18 19 \chaptertoc 20 21 \paragraph{Changes record} ~\\ 22 23 {\footnotesize 24 \begin{tabularx}{0.8\textwidth}{l||X|X} 25 Release & 26 Author(s) & 27 Modifications \\ 28 \hline 29 {\em 4.0 } & 30 {\em Simon M\"{u}ller \& Andrew Coward \newline \newline 31 Simona Flavoni and Tim Graham } & 32 {\em Compatibility changes: many options moved to external domain configuration tools 33 (see \autoref{apdx:DOMCFG}). \newline 34 Updates } \\ 35 {\em 3.6 } & 36 {\em Rachid Benshila, Christian \'{E}th\'{e}, Pierre Mathiot and Gurvan Madec } & 37 {\em Updates } \\ 38 {\em $\leq$ 3.4 } & 39 {\em Gurvan Madec and S\'{e}bastien Masson } & 40 {\em First version } 41 \end{tabularx} 42 } 43 44 \clearpage 45 46 Having defined the continuous equations in \autoref{chap:MB} and 47 chosen a time discretisation \autoref{chap:TD}, 48 we need to choose a grid for spatial discretisation and related numerical algorithms. 24 49 In the present chapter, we provide a general description of the staggered grid used in \NEMO, 25 and other information relevant to the main directory routines as well as the DOM (DOMain) directory. 26 27 % ================================================================ 28 % Fundamentals of the Discretisation 29 % ================================================================ 50 and other relevant information about the DOM (DOMain) source code modules. 51 52 %% ================================================================================================= 30 53 \section{Fundamentals of the discretisation} 31 54 \label{sec:DOM_basics} 32 55 33 % ------------------------------------------------------------------------------------------------------------- 34 % Arrangement of Variables 35 % ------------------------------------------------------------------------------------------------------------- 56 %% ================================================================================================= 36 57 \subsection{Arrangement of variables} 37 58 \label{subsec:DOM_cell} 38 59 39 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 40 \begin{figure}[!tb] 41 \begin{center} 42 \includegraphics[]{Fig_cell} 43 \caption{ 44 \protect\label{fig:cell} 45 Arrangement of variables. 46 $t$ indicates scalar points where temperature, salinity, density, pressure and 47 horizontal divergence are defined. 48 $(u,v,w)$ indicates vector points, and $f$ indicates vorticity points where both relative and 49 planetary vorticities are defined. 50 } 51 \end{center} 60 \begin{figure} 61 \centering 62 \includegraphics[width=0.33\textwidth]{DOM_cell} 63 \caption[Arrangement of variables in the unit cell of space domain]{ 64 Arrangement of variables in the unit cell of space domain. 65 $t$ indicates scalar points where 66 temperature, salinity, density, pressure and horizontal divergence are defined. 67 $(u,v,w)$ indicates vector points, and $f$ indicates vorticity points where 68 both relative and planetary vorticities are defined.} 69 \label{fig:DOM_cell} 52 70 \end{figure} 53 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 54 55 The numerical techniques used to solve the Primitive Equations in this model are based on the traditional, 56 centred second-order finite difference approximation. 57 Special attention has been given to the homogeneity of the solution in the three space directions. 71 72 The numerical techniques used to solve the Primitive Equations in this model are based on 73 the traditional, centred second-order finite difference approximation. 74 Special attention has been given to the homogeneity of the solution in the three spatial directions. 58 75 The arrangement of variables is the same in all directions. 59 It consists of cells centred on scalar points ($t$, $S$, $p$, $\rho$) with vector points $(u, v, w)$ defined in 60 the centre of each face of the cells (\autoref{fig:cell}). 61 This is the generalisation to three dimensions of the well-known ``C'' grid in Arakawa's classification 62 \citep{Mesinger_Arakawa_Bk76}. 63 The relative and planetary vorticity, $\zeta$ and $f$, are defined in the centre of each vertical edge and 64 the barotropic stream function $\psi$ is defined at horizontal points overlying the $\zeta$ and $f$-points. 65 66 The ocean mesh (\ie the position of all the scalar and vector points) is defined by the transformation that 67 gives $(\lambda,\varphi,z)$ as a function of $(i,j,k)$. 68 The grid-points are located at integer or integer and a half value of $(i,j,k)$ as indicated on \autoref{tab:cell}. 69 In all the following, subscripts $u$, $v$, $w$, $f$, $uw$, $vw$ or $fw$ indicate the position of 70 the grid-point where the scale factors are defined. 71 Each scale factor is defined as the local analytical value provided by \autoref{eq:scale_factors}. 76 It consists of cells centred on scalar points ($t$, $S$, $p$, $\rho$) with 77 vector points $(u, v, w)$ defined in the centre of each face of the cells (\autoref{fig:DOM_cell}). 78 This is the generalisation to three dimensions of the well-known ``C'' grid in 79 Arakawa's classification \citep{mesinger.arakawa_bk76}. 80 The relative and planetary vorticity, $\zeta$ and $f$, are defined in the centre of each 81 vertical edge and the barotropic stream function $\psi$ is defined at horizontal points overlying 82 the $\zeta$ and $f$-points. 83 84 The ocean mesh (\ie\ the position of all the scalar and vector points) is defined by 85 the transformation that gives $(\lambda,\varphi,z)$ as a function of $(i,j,k)$. 86 The grid-points are located at integer or integer and a half value of $(i,j,k)$ as indicated on 87 \autoref{tab:DOM_cell}. 88 In all the following, 89 subscripts $u$, $v$, $w$, $f$, $uw$, $vw$ or $fw$ indicate the position of the grid-point where 90 the scale factors are defined. 91 Each scale factor is defined as the local analytical value provided by \autoref{eq:MB_scale_factors}. 72 92 As a result, the mesh on which partial derivatives $\pd[]{\lambda}$, $\pd[]{\varphi}$ and 73 $\pd[]{z}$ are evaluated in a uniform mesh with a grid size of unity. 74 Discrete partial derivatives are formulated by the traditional, centred second order finite difference approximation 75 while the scale factors are chosen equal to their local analytical value. 93 $\pd[]{z}$ are evaluated is a uniform mesh with a grid size of unity. 94 Discrete partial derivatives are formulated by 95 the traditional, centred second order finite difference approximation while 96 the scale factors are chosen equal to their local analytical value. 76 97 An important point here is that the partial derivative of the scale factors must be evaluated by 77 98 centred finite difference approximation, not from their analytical expression. 78 This preserves the symmetry of the discrete set of equations and therefore satisfies many of79 the continuous properties (see \autoref{apdx:C}).99 This preserves the symmetry of the discrete set of equations and 100 therefore satisfies many of the continuous properties (see \autoref{apdx:INVARIANTS}). 80 101 A similar, related remark can be made about the domain size: 81 when needed, an area, volume, or the total ocean depth must be evaluated as the sum of the relevant scale factors 82 (see \autoref{eq:DOM_bar} in the next section). 83 84 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 85 \begin{table}[!tb] 86 \begin{center} 87 \begin{tabular}{|p{46pt}|p{56pt}|p{56pt}|p{56pt}|} 88 \hline 89 T & $i $ & $j $ & $k $ \\ 90 \hline 91 u & $i + 1/2$ & $j $ & $k $ \\ 92 \hline 93 v & $i $ & $j + 1/2$ & $k $ \\ 94 \hline 95 w & $i $ & $j $ & $k + 1/2$ \\ 96 \hline 97 f & $i + 1/2$ & $j + 1/2$ & $k $ \\ 98 \hline 99 uw & $i + 1/2$ & $j $ & $k + 1/2$ \\ 100 \hline 101 vw & $i $ & $j + 1/2$ & $k + 1/2$ \\ 102 \hline 103 fw & $i + 1/2$ & $j + 1/2$ & $k + 1/2$ \\ 104 \hline 105 \end{tabular} 106 \caption{ 107 \protect\label{tab:cell} 108 Location of grid-points as a function of integer or integer and a half value of the column, line or level. 109 This indexing is only used for the writing of the semi -discrete equation. 110 In the code, the indexing uses integer values only and has a reverse direction in the vertical 111 (see \autoref{subsec:DOM_Num_Index}) 112 } 113 \end{center} 102 when needed, an area, volume, or the total ocean depth must be evaluated as 103 the product or sum of the relevant scale factors (see \autoref{eq:DOM_bar} in the next section). 104 105 \begin{table} 106 \centering 107 \begin{tabular}{|l|l|l|l|} 108 \hline 109 t & $i $ & $j $ & $k $ \\ 110 \hline 111 u & $i + 1/2$ & $j $ & $k $ \\ 112 \hline 113 v & $i $ & $j + 1/2$ & $k $ \\ 114 \hline 115 w & $i $ & $j $ & $k + 1/2$ \\ 116 \hline 117 f & $i + 1/2$ & $j + 1/2$ & $k $ \\ 118 \hline 119 uw & $i + 1/2$ & $j $ & $k + 1/2$ \\ 120 \hline 121 vw & $i $ & $j + 1/2$ & $k + 1/2$ \\ 122 \hline 123 fw & $i + 1/2$ & $j + 1/2$ & $k + 1/2$ \\ 124 \hline 125 \end{tabular} 126 \caption[Location of grid-points]{ 127 Location of grid-points as a function of integer or 128 integer and a half value of the column, line or level. 129 This indexing is only used for the writing of the semi-discrete equations. 130 In the code, the indexing uses integer values only and 131 is positive downwards in the vertical with $k=1$ at the surface. 132 (see \autoref{subsec:DOM_Num_Index})} 133 \label{tab:DOM_cell} 114 134 \end{table} 115 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 116 117 % ------------------------------------------------------------------------------------------------------------- 118 % Vector Invariant Formulation 119 % ------------------------------------------------------------------------------------------------------------- 135 136 Note that the definition of the scale factors 137 (\ie\ as the analytical first derivative of the transformation that 138 results in $(\lambda,\varphi,z)$ as a function of $(i,j,k)$) 139 is specific to the \NEMO\ model \citep{marti.madec.ea_JGR92}. 140 As an example, a scale factor in the $i$ direction is defined locally at a $t$-point, 141 whereas many other models on a C grid choose to define such a scale factor as 142 the distance between the $u$-points on each side of the $t$-point. 143 Relying on an analytical transformation has two advantages: 144 firstly, there is no ambiguity in the scale factors appearing in the discrete equations, 145 since they are first introduced in the continuous equations; 146 secondly, analytical transformations encourage good practice by 147 the definition of smoothly varying grids 148 (rather than allowing the user to set arbitrary jumps in thickness between adjacent layers) 149 \citep{treguier.dukowicz.ea_JGR96}. 150 An example of the effect of such a choice is shown in \autoref{fig:DOM_zgr_e3}. 151 \begin{figure} 152 \centering 153 \includegraphics[width=0.5\textwidth]{DOM_zgr_e3} 154 \caption[Comparison of grid-point position, vertical grid-size and scale factors]{ 155 Comparison of (a) traditional definitions of grid-point position and grid-size in the vertical, 156 and (b) analytically derived grid-point position and scale factors. 157 For both grids here, the same $w$-point depth has been chosen but 158 in (a) the $t$-points are set half way between $w$-points while 159 in (b) they are defined from an analytical function: 160 $z(k) = 5 \, (k - 1/2)^3 - 45 \, (k - 1/2)^2 + 140 \, (k - 1/2) - 150$. 161 Note the resulting difference between the value of the grid-size $\Delta_k$ and 162 those of the scale factor $e_k$.} 163 \label{fig:DOM_zgr_e3} 164 \end{figure} 165 166 %% ================================================================================================= 120 167 \subsection{Discrete operators} 121 168 \label{subsec:DOM_operators} 122 169 123 Given the values of a variable $q$ at adjacent points, the differencing and averaging operators at124 the midpoint between them are:170 Given the values of a variable $q$ at adjacent points, 171 the differencing and averaging operators at the midpoint between them are: 125 172 \begin{alignat*}{2} 126 % \label{eq: di_mi}173 % \label{eq:DOM_di_mi} 127 174 \delta_i [q] &= & &q (i + 1/2) - q (i - 1/2) \\ 128 175 \overline q^{\, i} &= &\big\{ &q (i + 1/2) + q (i - 1/2) \big\} / 2 … … 130 177 131 178 Similar operators are defined with respect to $i + 1/2$, $j$, $j + 1/2$, $k$, and $k + 1/2$. 132 Following \autoref{eq:PE_grad} and \autoref{eq:PE_lap}, the gradient of a variable $q$ defined at 133 a $t$-point has its three components defined at $u$-, $v$- and $w$-points while 134 its Laplacian is defined at $t$-point. 179 Following \autoref{eq:MB_grad} and \autoref{eq:MB_lap}, 180 the gradient of a variable $q$ defined at a $t$-point has 181 its three components defined at $u$-, $v$- and $w$-points while 182 its Laplacian is defined at the $t$-point. 135 183 These operators have the following discrete forms in the curvilinear $s$-coordinates system: 136 \ [184 \begin{gather*} 137 185 % \label{eq:DOM_grad} 138 186 \nabla q \equiv \frac{1}{e_{1u}} \delta_{i + 1/2} [q] \; \, \vect i 139 187 + \frac{1}{e_{2v}} \delta_{j + 1/2} [q] \; \, \vect j 140 + \frac{1}{e_{3w}} \delta_{k + 1/2} [q] \; \, \vect k 141 \] 142 \begin{multline*} 188 + \frac{1}{e_{3w}} \delta_{k + 1/2} [q] \; \, \vect k \\ 143 189 % \label{eq:DOM_lap} 144 190 \Delta q \equiv \frac{1}{e_{1t} \, e_{2t} \, e_{3t}} 145 191 \; \lt[ \delta_i \lt( \frac{e_{2u} \, e_{3u}}{e_{1u}} \; \delta_{i + 1/2} [q] \rt) 146 + \delta_j \lt( \frac{e_{1v} \, e_{3v}}{e_{2v}} \; \delta_{j + 1/2} [q] \rt) \; \rt] \\192 + \delta_j \lt( \frac{e_{1v} \, e_{3v}}{e_{2v}} \; \delta_{j + 1/2} [q] \rt) \; \rt] 147 193 + \frac{1}{e_{3t}} 148 194 \delta_k \lt[ \frac{1 }{e_{3w}} \; \delta_{k + 1/2} [q] \rt] 149 \end{multline*} 150 151 Following \autoref{eq:PE_curl} and \autoref{eq:PE_div}, a vector $\vect A = (a_1,a_2,a_3)$ defined at 152 vector points $(u,v,w)$ has its three curl components defined at $vw$-, $uw$, and $f$-points, and 195 \end{gather*} 196 197 Following \autoref{eq:MB_curl} and \autoref{eq:MB_div}, 198 a vector $\vect A = (a_1,a_2,a_3)$ defined at vector points $(u,v,w)$ has 199 its three curl components defined at $vw$-, $uw$, and $f$-points, and 153 200 its divergence defined at $t$-points: 154 \begin{multline }201 \begin{multline*} 155 202 % \label{eq:DOM_curl} 156 203 \nabla \times \vect A \equiv \frac{1}{e_{2v} \, e_{3vw}} … … 163 210 \Big[ \delta_{i + 1/2} (e_{2v} \, a_2) 164 211 - \delta_{j + 1/2} (e_{1u} \, a_1) \Big] \vect k 165 \end{multline }166 \ begin{equation}212 \end{multline*} 213 \[ 167 214 % \label{eq:DOM_div} 168 215 \nabla \cdot \vect A \equiv \frac{1}{e_{1t} \, e_{2t} \, e_{3t}} 169 216 \Big[ \delta_i (e_{2u} \, e_{3u} \, a_1) + \delta_j (e_{1v} \, e_{3v} \, a_2) \Big] 170 217 + \frac{1}{e_{3t}} \delta_k (a_3) 171 \ end{equation}172 173 The vertical average over the whole water column denoted by an overbar becomes for a quantity $q$ which174 is a masked field (i.e. equal to zero inside solid area):218 \] 219 220 The vertical average over the whole water column is denoted by an overbar and 221 is for a masked field $q$ (\ie\ a quantity that is equal to zero inside solid areas): 175 222 \begin{equation} 176 223 \label{eq:DOM_bar} … … 178 225 \end{equation} 179 226 where $H_q$ is the ocean depth, which is the masked sum of the vertical scale factors at $q$ points, 180 $k^b$ and $k^o$ are the bottom and surface $k$-indices, and the symbol $k^o$ refers to a summation over 181 all grid points of the same type in the direction indicated by the subscript (here $k$). 227 $k^b$ and $k^o$ are the bottom and surface $k$-indices, 228 and the symbol $\sum \limits_k$ refers to a summation over all grid points of the same type in 229 the direction indicated by the subscript (here $k$). 182 230 183 231 In continuous form, the following properties are satisfied: … … 189 237 \end{gather} 190 238 191 It is straightforward to demonstrate that these properties are verified locally in discrete form as soon as192 the scalar $q$ is taken at $t$-points and the vector $\vect A$ has its components defined at239 It is straightforward to demonstrate that these properties are verified locally in discrete form as 240 soon as the scalar $q$ is taken at $t$-points and the vector $\vect A$ has its components defined at 193 241 vector points $(u,v,w)$. 194 242 195 Let $a$ and $b$ be two fields defined on the mesh, with value zero inside continental area. 196 Using integration by parts it can be shown that the differencing operators ($\delta_i$, $\delta_j$ and $\delta_k$) 197 are skew-symmetric linear operators, and further that the averaging operators $\overline{\cdots}^{\, i}$, 198 $\overline{\cdots}^{\, j}$ and $\overline{\cdots}^{\, k}$) are symmetric linear operators, \ie 199 \begin{alignat}{4} 243 Let $a$ and $b$ be two fields defined on the mesh, with a value of zero inside continental areas. 244 It can be shown that the differencing operators ($\delta_i$, $\delta_j$ and 245 $\delta_k$) are skew-symmetric linear operators, 246 and further that the averaging operators ($\overline{\cdots}^{\, i}$, $\overline{\cdots}^{\, j}$ and 247 $\overline{\cdots}^{\, k}$) are symmetric linear operators, \ie 248 \begin{alignat}{5} 200 249 \label{eq:DOM_di_adj} 201 250 &\sum \limits_i a_i \; \delta_i [b] &\equiv &- &&\sum \limits_i \delta _{ i + 1/2} [a] &b_{i + 1/2} \\ … … 204 253 \end{alignat} 205 254 206 In other words, the adjoint of the differencing and averaging operators are $\delta_i^* = \delta_{i + 1/2}$ and 255 In other words, 256 the adjoint of the differencing and averaging operators are $\delta_i^* = \delta_{i + 1/2}$ and 207 257 $(\overline{\cdots}^{\, i})^* = \overline{\cdots}^{\, i + 1/2}$, respectively. 208 These two properties will be used extensively in the \autoref{apdx: C} to258 These two properties will be used extensively in the \autoref{apdx:INVARIANTS} to 209 259 demonstrate integral conservative properties of the discrete formulation chosen. 210 260 211 % ------------------------------------------------------------------------------------------------------------- 212 % Numerical Indexing 213 % ------------------------------------------------------------------------------------------------------------- 261 %% ================================================================================================= 214 262 \subsection{Numerical indexing} 215 263 \label{subsec:DOM_Num_Index} 216 264 217 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 218 \begin{figure}[!tb] 219 \begin{center} 220 \includegraphics[]{Fig_index_hor} 221 \caption{ 222 \protect\label{fig:index_hor} 223 Horizontal integer indexing used in the \fortran code. 224 The dashed area indicates the cell in which variables contained in arrays have the same $i$- and $j$-indices 225 } 226 \end{center} 265 \begin{figure} 266 \centering 267 \includegraphics[width=0.33\textwidth]{DOM_index_hor} 268 \caption[Horizontal integer indexing]{ 269 Horizontal integer indexing used in the \fortran\ code. 270 The dashed area indicates the cell in which 271 variables contained in arrays have the same $i$- and $j$-indices} 272 \label{fig:DOM_index_hor} 227 273 \end{figure} 228 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 229 230 The array representation used in the \fortran code requires an integer indexing while 231 the analytical definition of the mesh (see \autoref{subsec:DOM_cell}) is associated with the use of 232 integer values for $t$-points and both integer and integer and a half values for all the other points. 233 Therefore a specific integer indexing must be defined for points other than $t$-points 234 (\ie velocity and vorticity grid-points). 235 Furthermore, the direction of the vertical indexing has been changed so that the surface level is at $k = 1$. 236 237 % ----------------------------------- 238 % Horizontal Indexing 239 % ----------------------------------- 274 275 The array representation used in the \fortran\ code requires an integer indexing. 276 However, the analytical definition of the mesh (see \autoref{subsec:DOM_cell}) is associated with 277 the use of integer values for $t$-points only while 278 all the other points involve integer and a half values. 279 Therefore, a specific integer indexing has been defined for points other than $t$-points 280 (\ie\ velocity and vorticity grid-points). 281 Furthermore, the direction of the vertical indexing has been reversed and 282 the surface level set at $k = 1$. 283 284 %% ================================================================================================= 240 285 \subsubsection{Horizontal indexing} 241 286 \label{subsec:DOM_Num_Index_hor} 242 287 243 The indexing in the horizontal plane has been chosen as shown in \autoref{fig: index_hor}.288 The indexing in the horizontal plane has been chosen as shown in \autoref{fig:DOM_index_hor}. 244 289 For an increasing $i$ index ($j$ index), 245 290 the $t$-point and the eastward $u$-point (northward $v$-point) have the same index 246 (see the dashed area in \autoref{fig:index_hor}). 247 A $t$-point and its nearest northeast $f$-point have the same $i$-and $j$-indices. 248 249 % ----------------------------------- 250 % Vertical indexing 251 % ----------------------------------- 291 (see the dashed area in \autoref{fig:DOM_index_hor}). 292 A $t$-point and its nearest north-east $f$-point have the same $i$-and $j$-indices. 293 294 %% ================================================================================================= 252 295 \subsubsection{Vertical indexing} 253 296 \label{subsec:DOM_Num_Index_vertical} 254 297 255 In the vertical, the chosen indexing requires special attention since the $k$-axis is re-orientated downward in 256 the \fortran code compared to the indexing used in the semi -discrete equations and 257 given in \autoref{subsec:DOM_cell}. 258 The sea surface corresponds to the $w$-level $k = 1$ which is the same index as $t$-level just below 259 (\autoref{fig:index_vert}). 260 The last $w$-level ($k = jpk$) either corresponds to the ocean floor or is inside the bathymetry while 261 the last $t$-level is always inside the bathymetry (\autoref{fig:index_vert}). 262 Note that for an increasing $k$ index, a $w$-point and the $t$-point just below have the same $k$ index, 263 in opposition to what is done in the horizontal plane where 264 it is the $t$-point and the nearest velocity points in the direction of the horizontal axis that 265 have the same $i$ or $j$ index 266 (compare the dashed area in \autoref{fig:index_hor} and \autoref{fig:index_vert}). 298 In the vertical, the chosen indexing requires special attention since 299 the direction of the $k$-axis in the \fortran\ code is the reverse of 300 that used in the semi-discrete equations and given in \autoref{subsec:DOM_cell}. 301 The sea surface corresponds to the $w$-level $k = 1$, 302 which is the same index as the $t$-level just below (\autoref{fig:DOM_index_vert}). 303 The last $w$-level ($k = jpk$) either corresponds to or is below the ocean floor while 304 the last $t$-level is always outside the ocean domain (\autoref{fig:DOM_index_vert}). 305 Note that a $w$-point and the directly underlaying $t$-point have a common $k$ index 306 (\ie\ $t$-points and their nearest $w$-point neighbour in negative index direction), 307 in contrast to the indexing on the horizontal plane where 308 the $t$-point has the same index as the nearest velocity points in 309 the positive direction of the respective horizontal axis index 310 (compare the dashed area in \autoref{fig:DOM_index_hor} and \autoref{fig:DOM_index_vert}). 267 311 Since the scale factors are chosen to be strictly positive, 268 a \textit{minus sign} appears in the \fortran code \textit{before all the vertical derivatives} of 269 the discrete equations given in this documentation. 270 271 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 272 \begin{figure}[!pt] 273 \begin{center} 274 \includegraphics[]{Fig_index_vert} 275 \caption{ 276 \protect\label{fig:index_vert} 277 Vertical integer indexing used in the \fortran code. 278 Note that the $k$-axis is orientated downward. 279 The dashed area indicates the cell in which variables contained in arrays have the same $k$-index. 280 } 281 \end{center} 312 a \textit{minus sign} is included in the \fortran\ implementations of 313 \textit{all the vertical derivatives} of the discrete equations given in this manual in order to 314 accommodate the opposing vertical index directions in implementation and documentation. 315 316 \begin{figure} 317 \centering 318 \includegraphics[width=0.33\textwidth]{DOM_index_vert} 319 \caption[Vertical integer indexing]{ 320 Vertical integer indexing used in the \fortran\ code. 321 Note that the $k$-axis is oriented downward. 322 The dashed area indicates the cell in which 323 variables contained in arrays have a common $k$-index.} 324 \label{fig:DOM_index_vert} 282 325 \end{figure} 283 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 284 285 % ----------------------------------- 286 % Domain Size 287 % ----------------------------------- 288 \subsubsection{Domain size} 326 327 %% ================================================================================================= 328 \section{Spatial domain configuration} 329 \label{subsec:DOM_config} 330 331 Two typical methods are available to specify the spatial domain configuration; 332 they can be selected using parameter \np{ln_read_cfg}{ln\_read\_cfg} parameter in 333 namelist \nam{cfg}{cfg}. 334 335 If \np{ln_read_cfg}{ln\_read\_cfg} is set to \forcode{.true.}, 336 the domain-specific parameters and fields are read from a NetCDF input file, 337 whose name (without its .nc suffix) can be specified as 338 the value of the \np{cn_domcfg}{cn\_domcfg} parameter in namelist \nam{cfg}{cfg}. 339 340 If \np{ln_read_cfg}{ln\_read\_cfg} is set to \forcode{.false.}, 341 the domain-specific parameters and fields can be provided (\eg\ analytically computed) by 342 subroutines \mdl{usrdef\_hgr} and \mdl{usrdef\_zgr}. 343 These subroutines can be supplied in the \path{MY_SRC} directory of the configuration, 344 and default versions that configure the spatial domain for the GYRE reference configuration are 345 present in the \path{./src/OCE/USR} directory. 346 347 In version 4.0 there are no longer any options for reading complex bathymetries and 348 performing a vertical discretisation at run-time. 349 Whilst it is occasionally convenient to have a common bathymetry file and, for example, 350 to run similar models with and without partial bottom boxes and/or sigma-coordinates, 351 supporting such choices leads to overly complex code. 352 Worse still is the difficulty of ensuring the model configurations intended to be identical are 353 indeed so when the model domain itself can be altered by runtime selections. 354 The code previously used to perform vertical discretisation has been incorporated into 355 an external tool (\path{./tools/DOMAINcfg}) which is briefly described in \autoref{apdx:DOMCFG}. 356 357 The next subsections summarise the parameter and fields related to 358 the configuration of the whole model domain. 359 These represent the minimum information that must be provided either via 360 the \np{cn_domcfg}{cn\_domcfg} file or 361 set by code inserted into user-supplied versions of the \texttt{usrdef\_*} subroutines. 362 The requirements are presented in three sections: 363 the domain size (\autoref{subsec:DOM_size}), the horizontal mesh (\autoref{subsec:DOM_hgr}), 364 and the vertical grid (\autoref{subsec:DOM_zgr}). 365 366 %% ================================================================================================= 367 \subsection{Domain size} 289 368 \label{subsec:DOM_size} 290 369 291 The total size of the computational domain is set by the parameters \np{jpiglo}, 292 \np{jpjglo} and \np{jpkglo} in the $i$, $j$ and $k$ directions respectively. 293 Parameters $jpi$ and $jpj$ refer to the size of each processor subdomain when 294 the code is run in parallel using domain decomposition (\key{mpp\_mpi} defined, 295 see \autoref{sec:LBC_mpp}). 296 297 % ================================================================ 298 % Domain: List of fields needed 299 % ================================================================ 300 \section{Needed fields} 301 \label{sec:DOM_fields} 302 The ocean mesh (\ie the position of all the scalar and vector points) is defined by the transformation that 303 gives $(\lambda,\varphi,z)$ as a function of $(i,j,k)$. 304 The grid-points are located at integer or integer and a half values of as indicated in \autoref{tab:cell}. 305 The associated scale factors are defined using the analytical first derivative of the transformation 306 \autoref{eq:scale_factors}. 307 Necessary fields for configuration definition are: 370 The total size of the computational domain is set by the parameters \jp{jpiglo}, \jp{jpjglo} and 371 \jp{jpkglo} for the $i$, $j$ and $k$ directions, respectively. 372 Note, that the variables \texttt{jpi} and \texttt{jpj} refer to 373 the size of each processor subdomain when the code is run in parallel using domain decomposition 374 (\key{mpp\_mpi} defined, see \autoref{sec:LBC_mpp}). 375 376 The name of the configuration is set through parameter \np{cn_cfg}{cn\_cfg}, 377 and the nominal resolution through parameter \np{nn_cfg}{nn\_cfg} 378 (unless in the input file both of variables \texttt{ORCA} and \texttt{ORCA\_index} are present, 379 in which case \np{cn_cfg}{cn\_cfg} and \np{nn_cfg}{nn\_cfg} are set from these values accordingly). 380 381 The global lateral boundary condition type is selected from 8 options using parameter \jp{jperio}. 382 See \autoref{sec:LBC_jperio} for details on the available options and 383 the corresponding values for \jp{jperio}. 384 385 %% ================================================================================================= 386 \subsection[Horizontal grid mesh (\textit{domhgr.F90}]{Horizontal grid mesh (\protect\mdl{domhgr})} 387 \label{subsec:DOM_hgr} 388 389 %% ================================================================================================= 390 \subsubsection{Required fields} 391 \label{sec:DOM_hgr_fields} 392 393 The explicit specification of a range of mesh-related fields are required for 394 the definition of a configuration. 395 These include: 396 397 \begin{clines} 398 int jpiglo, jpjglo, jpkglo /* global domain sizes */ 399 int jperio /* lateral global domain b.c. */ 400 double glamt, glamu, glamv, glamf /* geographic longitude (t,u,v and f points respectively) */ 401 double gphit, gphiu, gphiv, gphif /* geographic latitude */ 402 double e1t, e1u, e1v, e1f /* horizontal scale factors */ 403 double e2t, e2u, e2v, e2f /* horizontal scale factors */ 404 \end{clines} 405 406 The values of the geographic longitude and latitude arrays at indices $i,j$ correspond to 407 the analytical expressions of the longitude $\lambda$ and latitude $\varphi$ as a function of $(i,j)$, 408 evaluated at the values as specified in \autoref{tab:DOM_cell} for the respective grid-point position. 409 The calculation of the values of the horizontal scale factor arrays in general additionally involves 410 partial derivatives of $\lambda$ and $\varphi$ with respect to $i$ and $j$, 411 evaluated for the same arguments as $\lambda$ and $\varphi$. 412 413 %% ================================================================================================= 414 \subsubsection{Optional fields} 415 416 \begin{clines} 417 /* Optional: */ 418 int ORCA, ORCA_index /* configuration name, configuration resolution */ 419 double e1e2u, e1e2v /* U and V surfaces (if grid size reduction in some straits) */ 420 double ff_f, ff_t /* Coriolis parameter (if not on the sphere) */ 421 \end{clines} 422 423 \NEMO\ can support the local reduction of key strait widths by 424 altering individual values of e2u or e1v at the appropriate locations. 425 This is particularly useful for locations such as Gibraltar or Indonesian Throughflow pinch-points 426 (see \autoref{sec:MISC_strait} for illustrated examples). 427 The key is to reduce the faces of $T$-cell 428 (\ie\ change the value of the horizontal scale factors at $u$- or $v$-point) but 429 not the volume of the cells. 430 Doing otherwise can lead to numerical instability issues. 431 In normal operation the surface areas are computed from $e1u * e2u$ and $e1v * e2v$ but 432 in cases where a gridsize reduction is required, 433 the unaltered surface areas at $u$ and $v$ grid points 434 (\texttt{e1e2u} and \texttt{e1e2v}, respectively) must be read or pre-computed in \mdl{usrdef\_hgr}. 435 If these arrays are present in the \np{cn_domcfg}{cn\_domcfg} file they are read and 436 the internal computation is suppressed. 437 Versions of \mdl{usrdef\_hgr} which set their own values of \texttt{e1e2u} and \texttt{e1e2v} should 438 set the surface-area computation flag: 439 \texttt{ie1e2u\_v} to a non-zero value to suppress their re-computation. 440 441 \smallskip 442 Similar logic applies to the other optional fields: 443 \texttt{ff\_f} and \texttt{ff\_t} which can be used to 444 provide the Coriolis parameter at F- and T-points respectively if the mesh is not on a sphere. 445 If present these fields will be read and used and 446 the normal calculation ($2 * \Omega * \sin(\varphi)$) suppressed. 447 Versions of \mdl{usrdef\_hgr} which set their own values of \texttt{ff\_f} and \texttt{ff\_t} should 448 set the Coriolis computation flag: 449 \texttt{iff} to a non-zero value to suppress their re-computation. 450 451 Note that longitudes, latitudes, and scale factors at $w$ points are exactly equal to 452 those of $t$ points, thus no specific arrays are defined at $w$ points. 453 454 %% ================================================================================================= 455 \subsection[Vertical grid (\textit{domzgr.F90})]{Vertical grid (\protect\mdl{domzgr})} 456 \label{subsec:DOM_zgr} 457 458 \begin{listing} 459 \nlst{namdom} 460 \caption{\forcode{&namdom}} 461 \label{lst:namdom} 462 \end{listing} 463 464 In the vertical, the model mesh is determined by four things: 465 \begin{enumerate} 466 \item the bathymetry given in meters; 467 \item the number of levels of the model (\jp{jpk}); 468 \item the analytical transformation $z(i,j,k)$ and the vertical scale factors 469 (derivatives of the transformation); and 470 \item the masking system, 471 \ie\ the number of wet model levels at each $(i,j)$ location of the horizontal grid. 472 \end{enumerate} 473 474 \begin{figure} 475 \centering 476 \includegraphics[width=0.5\textwidth]{DOM_z_zps_s_sps} 477 \caption[Ocean bottom regarding coordinate systems ($z$, $s$ and hybrid $s-z$)]{ 478 The ocean bottom as seen by the model: 479 \begin{enumerate*}[label=(\textit{\alph*})] 480 \item $z$-coordinate with full step, 481 \item $z$-coordinate with partial step, 482 \item $s$-coordinate: terrain following representation, 483 \item hybrid $s-z$ coordinate, 484 \item hybrid $s-z$ coordinate with partial step, and 485 \item same as (e) but in the non-linear free surface 486 (\protect\np[=.false.]{ln_linssh}{ln\_linssh}). 487 \end{enumerate*} 488 Note that the non-linear free surface can be used with any of the 5 coordinates (a) to (e).} 489 \label{fig:DOM_z_zps_s_sps} 490 \end{figure} 491 492 The choice of a vertical coordinate is made when setting up the configuration; 493 it is not intended to be an option which can be changed in the middle of an experiment. 494 The one exception to this statement being the choice of linear or non-linear free surface. 495 In v4.0 the linear free surface option is implemented as 496 a special case of the non-linear free surface. 497 This is computationally wasteful since it uses the structures for time-varying 3D metrics 498 for fields that (in the linear free surface case) are fixed. 499 However, the linear free-surface is rarely used and 500 implementing it this way means a single configuration file can support both options. 501 502 By default a non-linear free surface is used 503 (\np{ln_linssh}{ln\_linssh} set to \forcode{=.false.} in \nam{dom}{dom}): 504 the coordinate follow the time-variation of the free surface so that 505 the transformation is time dependent: $z(i,j,k,t)$ (\eg\ \autoref{fig:DOM_z_zps_s_sps}f). 506 When a linear free surface is assumed 507 (\np{ln_linssh}{ln\_linssh} set to \forcode{=.true.} in \nam{dom}{dom}), 508 the vertical coordinates are fixed in time, but 509 the seawater can move up and down across the $z_0$ surface 510 (in other words, the top of the ocean in not a rigid lid). 511 512 Note that settings: 513 \np{ln_zco}{ln\_zco}, \np{ln_zps}{ln\_zps}, \np{ln_sco}{ln\_sco} and \np{ln_isfcav}{ln\_isfcav} 514 mentioned in the following sections appear to be namelist options but 515 they are no longer truly namelist options for \NEMO. 516 Their value is written to and read from the domain configuration file and 517 they should be treated as fixed parameters for a particular configuration. 518 They are namelist options for the \texttt{DOMAINcfg} tool that can be used to 519 build the configuration file and serve both to provide a record of the choices made whilst 520 building the configuration and to trigger appropriate code blocks within \NEMO. 521 These values should not be altered in the \np{cn_domcfg}{cn\_domcfg} file. 522 523 \medskip 524 The decision on these choices must be made when the \np{cn_domcfg}{cn\_domcfg} file is constructed. 525 Three main choices are offered (\autoref{fig:DOM_z_zps_s_sps}a-c): 308 526 309 527 \begin{itemize} 310 \item 311 Geographic position: 312 longitude with \texttt{glamt}, \texttt{glamu}, \texttt{glamv}, \texttt{glamf} and 313 latitude with \texttt{gphit}, \texttt{gphiu}, \texttt{gphiv}, \texttt{gphif} 314 (all respectively at T, U, V and F point) 315 \item 316 Coriolis parameter (if domain not on the sphere): \texttt{ff\_f} and \texttt{ff\_t} 317 (at T and F point) 318 \item 319 Scale factors: 320 \texttt{e1t}, \texttt{e1u}, \texttt{e1v} and \texttt{e1f} (on i direction), 321 \texttt{e2t}, \texttt{e2u}, \texttt{e2v} and \texttt{e2f} (on j direction) and 322 \texttt{ie1e2u\_v}, \texttt{e1e2u}, \texttt{e1e2v}. \\ 323 \texttt{e1e2u}, \texttt{e1e2v} are u and v surfaces (if gridsize reduction in some straits), 324 \texttt{ie1e2u\_v} is to flag set u and v surfaces are neither read nor computed. 528 \item $z$-coordinate with full step bathymetry (\np[=.true.]{ln_zco}{ln\_zco}), 529 \item $z$-coordinate with partial step ($zps$) bathymetry (\np[=.true.]{ln_zps}{ln\_zps}), 530 \item Generalized, $s$-coordinate (\np[=.true.]{ln_sco}{ln\_sco}). 325 531 \end{itemize} 326 327 These fields can be read in an domain input file which name is setted in \np{cn\_domcfg} parameter specified in 328 \ngn{namcfg}. 329 330 \nlst{namcfg} 331 332 Or they can be defined in an analytical way in \path{MY_SRC} directory of the configuration. 333 For Reference Configurations of NEMO input domain files are supplied by NEMO System Team. 334 For analytical definition of input fields two routines are supplied: \mdl{usrdef\_hgr} and \mdl{usrdef\_zgr}. 335 They are an example of GYRE configuration parameters, and they are available in \path{src/OCE/USR} directory, 336 they provide the horizontal and vertical mesh. 337 % ------------------------------------------------------------------------------------------------------------- 338 % Needed fields 339 % ------------------------------------------------------------------------------------------------------------- 340 %\subsection{List of needed fields to build DOMAIN} 341 %\label{subsec:DOM_fields_list} 342 343 344 % ================================================================ 345 % Domain: Horizontal Grid (mesh) 346 % ================================================================ 347 \section{Horizontal grid mesh (\protect\mdl{domhgr})} 348 \label{sec:DOM_hgr} 349 350 % ------------------------------------------------------------------------------------------------------------- 351 % Coordinates and scale factors 352 % ------------------------------------------------------------------------------------------------------------- 353 \subsection{Coordinates and scale factors} 354 \label{subsec:DOM_hgr_coord_e} 355 356 The ocean mesh (\ie the position of all the scalar and vector points) is defined by 357 the transformation that gives $(\lambda,\varphi,z)$ as a function of $(i,j,k)$. 358 The grid-points are located at integer or integer and a half values of as indicated in \autoref{tab:cell}. 359 The associated scale factors are defined using the analytical first derivative of the transformation 360 \autoref{eq:scale_factors}. 361 These definitions are done in two modules, \mdl{domhgr} and \mdl{domzgr}, 362 which provide the horizontal and vertical meshes, respectively. 363 This section deals with the horizontal mesh parameters. 364 365 In a horizontal plane, the location of all the model grid points is defined from 366 the analytical expressions of the longitude $\lambda$ and latitude $\varphi$ as a function of $(i,j)$. 367 The horizontal scale factors are calculated using \autoref{eq:scale_factors}. 368 For example, when the longitude and latitude are function of a single value 369 ($i$ and $j$, respectively) (geographical configuration of the mesh), 370 the horizontal mesh definition reduces to define the wanted $\lambda(i)$, $\varphi(j)$, 371 and their derivatives $\lambda'(i) \ \varphi'(j)$ in the \mdl{domhgr} module. 372 The model computes the grid-point positions and scale factors in the horizontal plane as follows: 532 533 Additionally, hybrid combinations of the three main coordinates are available: 534 $s-z$ or $s-zps$ coordinate (\autoref{fig:DOM_z_zps_s_sps}d and \autoref{fig:DOM_z_zps_s_sps}e). 535 536 A further choice related to vertical coordinate concerns 537 the presence (or not) of ocean cavities beneath ice shelves within the model domain. 538 A setting of \np{ln_isfcav}{ln\_isfcav} as \forcode{.true.} indicates that 539 the domain contains ocean cavities, 540 otherwise the top, wet layer of the ocean will always be at the ocean surface. 541 This option is currently only available for $z$- or $zps$-coordinates. 542 In the latter case, partial steps are also applied at the ocean/ice shelf interface. 543 544 Within the model, 545 the arrays describing the grid point depths and vertical scale factors are 546 three set of three dimensional arrays $(i,j,k)$ defined at 547 \textit{before}, \textit{now} and \textit{after} time step. 548 The time at which they are defined is indicated by a suffix: $\_b$, $\_n$, or $\_a$, respectively. 549 They are updated at each model time step. 550 The initial fixed reference coordinate system is held in variable names with a $\_0$ suffix. 551 When the linear free surface option is used (\np[=.true.]{ln_linssh}{ln\_linssh}), 552 \textit{before}, \textit{now} and \textit{after} arrays are initially set to 553 their reference counterpart and remain fixed. 554 555 %% ================================================================================================= 556 \subsubsection{Required fields} 557 \label{sec:DOM_zgr_fields} 558 559 The explicit specification of a range of fields related to the vertical grid are required for 560 the definition of a configuration. 561 These include: 562 563 \begin{clines} 564 int ln_zco, ln_zps, ln_sco /* flags for z-coord, z-coord with partial steps and s-coord */ 565 int ln_isfcav /* flag for ice shelf cavities */ 566 double e3t_1d, e3w_1d /* reference vertical scale factors at T and W points */ 567 double e3t_0, e3u_0, e3v_0, e3f_0, e3w_0 /* vertical scale factors 3D coordinate at T,U,V,F and W points */ 568 double e3uw_0, e3vw_0 /* vertical scale factors 3D coordinate at UW and VW points */ 569 int bottom_level, top_level /* last wet T-points, 1st wet T-points (for ice shelf cavities) */ 570 /* For reference: */ 571 float bathy_metry /* bathymetry used in setting top and bottom levels */ 572 \end{clines} 573 574 This set of vertical metrics is sufficient to describe the initial depth and thickness of 575 every gridcell in the model regardless of the choice of vertical coordinate. 576 With constant z-levels, e3 metrics will be uniform across each horizontal level. 577 In the partial step case each e3 at the \jp{bottom\_level} 578 (and, possibly, \jp{top\_level} if ice cavities are present) 579 may vary from its horizontal neighbours. 580 And, in s-coordinates, variations can occur throughout the water column. 581 With the non-linear free-surface, all the coordinates behave more like the s-coordinate in that 582 variations occur throughout the water column with displacements related to the sea surface height. 583 These variations are typically much smaller than those arising from bottom fitted coordinates. 584 The values for vertical metrics supplied in the domain configuration file can be considered as 585 those arising from a flat sea surface with zero elevation. 586 587 The \jp{bottom\_level} and \jp{top\_level} 2D arrays define 588 the \jp{bottom\_level} and top wet levels in each grid column. 589 Without ice cavities, \jp{top\_level} is essentially a land mask (0 on land; 1 everywhere else). 590 With ice cavities, \jp{top\_level} determines the first wet point below the overlying ice shelf. 591 592 %% ================================================================================================= 593 \subsubsection{Level bathymetry and mask} 594 \label{subsec:DOM_msk} 595 596 From \jp{top\_level} and \jp{bottom\_level} fields, the mask fields are defined as follows: 373 597 \begin{align*} 374 \lambda_t &\equiv \text{glamt} = \lambda (i ) 375 &\varphi_t &\equiv \text{gphit} = \varphi (j ) \\ 376 \lambda_u &\equiv \text{glamu} = \lambda (i + 1/2) 377 &\varphi_u &\equiv \text{gphiu} = \varphi (j ) \\ 378 \lambda_v &\equiv \text{glamv} = \lambda (i ) 379 &\varphi_v &\equiv \text{gphiv} = \varphi (j + 1/2) \\ 380 \lambda_f &\equiv \text{glamf} = \lambda (i + 1/2) 381 &\varphi_f &\equiv \text{gphif} = \varphi (j + 1/2) \\ 382 e_{1t} &\equiv \text{e1t} = r_a |\lambda'(i ) \; \cos\varphi(j ) | 383 &e_{2t} &\equiv \text{e2t} = r_a |\varphi'(j ) | \\ 384 e_{1u} &\equiv \text{e1t} = r_a |\lambda'(i + 1/2) \; \cos\varphi(j ) | 385 &e_{2u} &\equiv \text{e2t} = r_a |\varphi'(j ) | \\ 386 e_{1v} &\equiv \text{e1t} = r_a |\lambda'(i ) \; \cos\varphi(j + 1/2) | 387 &e_{2v} &\equiv \text{e2t} = r_a |\varphi'(j + 1/2) | \\ 388 e_{1f} &\equiv \text{e1t} = r_a |\lambda'(i + 1/2) \; \cos\varphi(j + 1/2) | 389 &e_{2f} &\equiv \text{e2t} = r_a |\varphi'(j + 1/2) | 598 tmask(i,j,k) &= 599 \begin{cases} 600 0 &\text{if $ k < top\_level(i,j)$} \\ 601 1 &\text{if $ bottom\_level(i,j) \leq k \leq top\_level(i,j)$} \\ 602 0 &\text{if $k > bottom\_level(i,j) $} 603 \end{cases} \\ 604 umask(i,j,k) &= tmask(i,j,k) * tmask(i + 1,j, k) \\ 605 vmask(i,j,k) &= tmask(i,j,k) * tmask(i ,j + 1,k) \\ 606 fmask(i,j,k) &= tmask(i,j,k) * tmask(i + 1,j, k) * tmask(i,j,k) * tmask(i + 1,j, k) \\ 607 wmask(i,j,k) &= tmask(i,j,k) * tmask(i ,j,k - 1) \\ 608 \text{with~} wmask(i,j,1) &= tmask(i,j,1) 390 609 \end{align*} 391 where the last letter of each computational name indicates the grid point considered and 392 $r_a$ is the earth radius (defined in \mdl{phycst} along with all universal constants). 393 Note that the horizontal position of and scale factors at $w$-points are exactly equal to those of $t$-points, 394 thus no specific arrays are defined at $w$-points. 395 396 Note that the definition of the scale factors 397 (\ie as the analytical first derivative of the transformation that 398 gives $(\lambda,\varphi,z)$ as a function of $(i,j,k)$) 399 is specific to the \NEMO model \citep{Marti_al_JGR92}. 400 As an example, $e_{1t}$ is defined locally at a $t$-point, 401 whereas many other models on a C grid choose to define such a scale factor as 402 the distance between the $U$-points on each side of the $t$-point. 403 Relying on an analytical transformation has two advantages: 404 firstly, there is no ambiguity in the scale factors appearing in the discrete equations, 405 since they are first introduced in the continuous equations; 406 secondly, analytical transformations encourage good practice by the definition of smoothly varying grids 407 (rather than allowing the user to set arbitrary jumps in thickness between adjacent layers) \citep{Treguier1996}. 408 An example of the effect of such a choice is shown in \autoref{fig:zgr_e3}. 409 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 410 \begin{figure}[!t] 411 \begin{center} 412 \includegraphics[]{Fig_zgr_e3} 413 \caption{ 414 \protect\label{fig:zgr_e3} 415 Comparison of (a) traditional definitions of grid-point position and grid-size in the vertical, 416 and (b) analytically derived grid-point position and scale factors. 417 For both grids here, the same $w$-point depth has been chosen but 418 in (a) the $t$-points are set half way between $w$-points while 419 in (b) they are defined from an analytical function: 420 $z(k) = 5 \, (k - 1/2)^3 - 45 \, (k - 1/2)^2 + 140 \, (k - 1/2) - 150$. 421 Note the resulting difference between the value of the grid-size $\Delta_k$ and 422 those of the scale factor $e_k$. 423 } 424 \end{center} 425 \end{figure} 426 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 427 428 % ------------------------------------------------------------------------------------------------------------- 429 % Choice of horizontal grid 430 % ------------------------------------------------------------------------------------------------------------- 431 \subsection{Choice of horizontal grid} 432 \label{subsec:DOM_hgr_msh_choice} 433 434 % ------------------------------------------------------------------------------------------------------------- 435 % Grid files 436 % ------------------------------------------------------------------------------------------------------------- 437 \subsection{Output grid files} 438 \label{subsec:DOM_hgr_files} 439 440 All the arrays relating to a particular ocean model configuration (grid-point position, scale factors, masks) 441 can be saved in files if \np{nn\_msh} $\not = 0$ (namelist variable in \ngn{namdom}). 442 This can be particularly useful for plots and off-line diagnostics. 443 In some cases, the user may choose to make a local modification of a scale factor in the code. 444 This is the case in global configurations when restricting the width of a specific strait 445 (usually a one-grid-point strait that happens to be too wide due to insufficient model resolution). 446 An example is Gibraltar Strait in the ORCA2 configuration. 447 When such modifications are done, 448 the output grid written when \np{nn\_msh} $\not = 0$ is no more equal to the input grid. 449 450 % ================================================================ 451 % Domain: Vertical Grid (domzgr) 452 % ================================================================ 453 \section{Vertical grid (\protect\mdl{domzgr})} 454 \label{sec:DOM_zgr} 455 %-----------------------------------------nam_zgr & namdom------------------------------------------- 456 % 457 %\nlst{namzgr} 458 459 \nlst{namdom} 460 %------------------------------------------------------------------------------------------------------------- 461 462 Variables are defined through the \ngn{namzgr} and \ngn{namdom} namelists. 463 In the vertical, the model mesh is determined by four things: 464 (1) the bathymetry given in meters; 465 (2) the number of levels of the model (\jp{jpk}); 466 (3) the analytical transformation $z(i,j,k)$ and the vertical scale factors (derivatives of the transformation); and 467 (4) the masking system, \ie the number of wet model levels at each 468 $(i,j)$ column of points. 469 470 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 \begin{figure}[!tb] 472 \begin{center} 473 \includegraphics[]{Fig_z_zps_s_sps} 474 \caption{ 475 \protect\label{fig:z_zps_s_sps} 476 The ocean bottom as seen by the model: 477 (a) $z$-coordinate with full step, 478 (b) $z$-coordinate with partial step, 479 (c) $s$-coordinate: terrain following representation, 480 (d) hybrid $s-z$ coordinate, 481 (e) hybrid $s-z$ coordinate with partial step, and 482 (f) same as (e) but in the non-linear free surface (\protect\np{ln\_linssh}~\forcode{= .false.}). 483 Note that the non-linear free surface can be used with any of the 5 coordinates (a) to (e). 484 } 485 \end{center} 486 \end{figure} 487 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 488 489 The choice of a vertical coordinate, even if it is made through \ngn{namzgr} namelist parameters, 490 must be done once of all at the beginning of an experiment. 491 It is not intended as an option which can be enabled or disabled in the middle of an experiment. 492 Three main choices are offered (\autoref{fig:z_zps_s_sps}): 493 $z$-coordinate with full step bathymetry (\np{ln\_zco}~\forcode{= .true.}), 494 $z$-coordinate with partial step bathymetry (\np{ln\_zps}~\forcode{= .true.}), 495 or generalized, $s$-coordinate (\np{ln\_sco}~\forcode{= .true.}). 496 Hybridation of the three main coordinates are available: 497 $s-z$ or $s-zps$ coordinate (\autoref{fig:z_zps_s_sps} and \autoref{fig:z_zps_s_sps}). 498 By default a non-linear free surface is used: the coordinate follow the time-variation of the free surface so that 499 the transformation is time dependent: $z(i,j,k,t)$ (\autoref{fig:z_zps_s_sps}). 500 When a linear free surface is assumed (\np{ln\_linssh}~\forcode{= .true.}), 501 the vertical coordinate are fixed in time, but the seawater can move up and down across the $z_0$ surface 502 (in other words, the top of the ocean in not a rigid-lid). 503 The last choice in terms of vertical coordinate concerns the presence (or not) in 504 the model domain of ocean cavities beneath ice shelves. 505 Setting \np{ln\_isfcav} to true allows to manage ocean cavities, otherwise they are filled in. 506 This option is currently only available in $z$- or $zps$-coordinate, 507 and partial step are also applied at the ocean/ice shelf interface. 508 509 Contrary to the horizontal grid, the vertical grid is computed in the code and no provision is made for 510 reading it from a file. 511 The only input file is the bathymetry (in meters) (\ifile{bathy\_meter}) 512 \footnote{ 513 N.B. in full step $z$-coordinate, a \ifile{bathy\_level} file can replace the \ifile{bathy\_meter} file, 514 so that the computation of the number of wet ocean point in each water column is by-passed}. 515 If \np{ln\_isfcav}~\forcode{= .true.}, an extra file input file (\ifile{isf\_draft\_meter}) describing 516 the ice shelf draft (in meters) is needed. 517 518 After reading the bathymetry, the algorithm for vertical grid definition differs between the different options: 519 \begin{description} 520 \item[\textit{zco}] 521 set a reference coordinate transformation $z_0(k)$, and set $z(i,j,k,t) = z_0(k)$. 522 \item[\textit{zps}] 523 set a reference coordinate transformation $z_0(k)$, and calculate the thickness of the deepest level at 524 each $(i,j)$ point using the bathymetry, to obtain the final three-dimensional depth and scale factor arrays. 525 \item[\textit{sco}] 526 smooth the bathymetry to fulfill the hydrostatic consistency criteria and 527 set the three-dimensional transformation. 528 \item[\textit{s-z} and \textit{s-zps}] 529 smooth the bathymetry to fulfill the hydrostatic consistency criteria and 530 set the three-dimensional transformation $z(i,j,k)$, 531 and possibly introduce masking of extra land points to better fit the original bathymetry file. 532 \end{description} 533 %%% 534 \gmcomment{ add the description of the smoothing: envelop topography...} 535 %%% 536 537 Unless a linear free surface is used (\np{ln\_linssh}~\forcode{= .false.}), 538 the arrays describing the grid point depths and vertical scale factors are three set of 539 three dimensional arrays $(i,j,k)$ defined at \textit{before}, \textit{now} and \textit{after} time step. 540 The time at which they are defined is indicated by a suffix: $\_b$, $\_n$, or $\_a$, respectively. 541 They are updated at each model time step using a fixed reference coordinate system which 542 computer names have a $\_0$ suffix. 543 When the linear free surface option is used (\np{ln\_linssh}~\forcode{= .true.}), \textit{before}, 544 \textit{now} and \textit{after} arrays are simply set one for all to their reference counterpart. 545 546 % ------------------------------------------------------------------------------------------------------------- 547 % Meter Bathymetry 548 % ------------------------------------------------------------------------------------------------------------- 549 \subsection{Meter bathymetry} 550 \label{subsec:DOM_bathy} 551 552 Three options are possible for defining the bathymetry, according to the namelist variable \np{nn\_bathy} 553 (found in \ngn{namdom} namelist): 554 \begin{description} 555 \item[\np{nn\_bathy}~\forcode{= 0}]: 556 a flat-bottom domain is defined. 557 The total depth $z_w (jpk)$ is given by the coordinate transformation. 558 The domain can either be a closed basin or a periodic channel depending on the parameter \np{jperio}. 559 \item[\np{nn\_bathy}~\forcode{= -1}]: 560 a domain with a bump of topography one third of the domain width at the central latitude. 561 This is meant for the "EEL-R5" configuration, a periodic or open boundary channel with a seamount. 562 \item[\np{nn\_bathy}~\forcode{= 1}]: 563 read a bathymetry and ice shelf draft (if needed). 564 The \ifile{bathy\_meter} file (Netcdf format) provides the ocean depth (positive, in meters) at 565 each grid point of the model grid. 566 The bathymetry is usually built by interpolating a standard bathymetry product (\eg ETOPO2) onto 567 the horizontal ocean mesh. 568 Defining the bathymetry also defines the coastline: where the bathymetry is zero, 569 no model levels are defined (all levels are masked). 570 571 The \ifile{isfdraft\_meter} file (Netcdf format) provides the ice shelf draft (positive, in meters) at 572 each grid point of the model grid. 573 This file is only needed if \np{ln\_isfcav}~\forcode{= .true.}. 574 Defining the ice shelf draft will also define the ice shelf edge and the grounding line position. 575 \end{description} 576 577 When a global ocean is coupled to an atmospheric model it is better to represent all large water bodies 578 (\eg great lakes, Caspian sea...) even if the model resolution does not allow their communication with 579 the rest of the ocean. 610 611 Note that, without ice shelves cavities, 612 masks at $t-$ and $w-$points are identical with the numerical indexing used 613 (\autoref{subsec:DOM_Num_Index}). 614 Nevertheless, 615 $wmask$ are required with ocean cavities to deal with the top boundary (ice shelf/ocean interface) 616 exactly in the same way as for the bottom boundary. 617 618 %% The specification of closed lateral boundaries requires that at least 619 %% the first and last rows and columns of the \textit{mbathy} array are set to zero. 620 %% In the particular case of an east-west cyclical boundary condition, \textit{mbathy} has its last column equal to 621 %% the second one and its first column equal to the last but one (and so too the mask arrays) 622 %% (see \autoref{fig:LBC_jperio}). 623 624 % Closed seas 625 %% ================================================================================================= 626 \subsection{Closed seas} 627 \label{subsec:DOM_closea} 628 629 When a global ocean is coupled to an atmospheric model it is better to 630 represent all large water bodies (\eg\ Great Lakes, Caspian sea, \dots) even if 631 the model resolution does not allow their communication with the rest of the ocean. 580 632 This is unnecessary when the ocean is forced by fixed atmospheric conditions, 581 633 so these seas can be removed from the ocean domain. 582 The user has the option to set the bathymetry in closed seas to zero (see \autoref{sec:MISC_closea}), 583 but the code has to be adapted to the user's configuration. 584 585 % ------------------------------------------------------------------------------------------------------------- 586 % z-coordinate and reference coordinate transformation 587 % ------------------------------------------------------------------------------------------------------------- 588 \subsection[$Z$-coordinate (\protect\np{ln\_zco}~\forcode{= .true.}) and ref. coordinate] 589 {$Z$-coordinate (\protect\np{ln\_zco}~\forcode{= .true.}) and reference coordinate} 590 \label{subsec:DOM_zco} 591 592 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 593 \begin{figure}[!tb] 594 \begin{center} 595 \includegraphics[]{Fig_zgr} 596 \caption{ 597 \protect\label{fig:zgr} 598 Default vertical mesh for ORCA2: 30 ocean levels (L30). 599 Vertical level functions for (a) T-point depth and (b) the associated scale factor as computed from 600 \autoref{eq:DOM_zgr_ana_1} using \autoref{eq:DOM_zgr_coef} in $z$-coordinate. 601 } 602 \end{center} 603 \end{figure} 604 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 605 606 The reference coordinate transformation $z_0(k)$ defines the arrays $gdept_0$ and $gdepw_0$ for $t$- and $w$-points, 607 respectively. 608 As indicated on \autoref{fig:index_vert} \jp{jpk} is the number of $w$-levels. 609 $gdepw_0(1)$ is the ocean surface. 610 There are at most \jp{jpk}-1 $t$-points inside the ocean, 611 the additional $t$-point at $jk = jpk$ is below the sea floor and is not used. 612 The vertical location of $w$- and $t$-levels is defined from the analytic expression of the depth $z_0(k)$ whose 613 analytical derivative with respect to $k$ provides the vertical scale factors. 614 The user must provide the analytical expression of both $z_0$ and its first derivative with respect to $k$. 615 This is done in routine \mdl{domzgr} through statement functions, 616 using parameters provided in the \ngn{namcfg} namelist. 617 618 It is possible to define a simple regular vertical grid by giving zero stretching (\np{ppacr}~\forcode{= 0}). 619 In that case, the parameters \jp{jpk} (number of $w$-levels) and 620 \np{pphmax} (total ocean depth in meters) fully define the grid. 621 622 For climate-related studies it is often desirable to concentrate the vertical resolution near the ocean surface. 623 The following function is proposed as a standard for a $z$-coordinate (with either full or partial steps): 624 \begin{gather} 625 \label{eq:DOM_zgr_ana_1} 626 z_0 (k) = h_{sur} - h_0 \; k - \; h_1 \; \log \big[ \cosh ((k - h_{th}) / h_{cr}) \big] \\ 627 e_3^0(k) = \lt| - h_0 - h_1 \; \tanh \big[ (k - h_{th}) / h_{cr} \big] \rt| 628 \end{gather} 629 where $k = 1$ to \jp{jpk} for $w$-levels and $k = 1$ to $k = 1$ for $T-$levels. 630 Such an expression allows us to define a nearly uniform vertical location of levels at the ocean top and bottom with 631 a smooth hyperbolic tangent transition in between (\autoref{fig:zgr}). 632 633 If the ice shelf cavities are opened (\np{ln\_isfcav}~\forcode{= .true.}), the definition of $z_0$ is the same. 634 However, definition of $e_3^0$ at $t$- and $w$-points is respectively changed to: 635 \begin{equation} 636 \label{eq:DOM_zgr_ana_2} 637 \begin{split} 638 e_3^T(k) &= z_W (k + 1) - z_W (k ) \\ 639 e_3^W(k) &= z_T (k ) - z_T (k - 1) 640 \end{split} 641 \end{equation} 642 This formulation decrease the self-generated circulation into the ice shelf cavity 643 (which can, in extreme case, leads to blow up).\\ 644 645 The most used vertical grid for ORCA2 has $10~m$ ($500~m$) resolution in the surface (bottom) layers and 646 a depth which varies from 0 at the sea surface to a minimum of $-5000~m$. 647 This leads to the following conditions: 648 \begin{equation} 649 \label{eq:DOM_zgr_coef} 650 \begin{array}{ll} 651 e_3 (1 + 1/2) = 10. & z(1 ) = 0. \\ 652 e_3 (jpk - 1/2) = 500. & z(jpk) = -5000. 653 \end{array} 654 \end{equation} 655 656 With the choice of the stretching $h_{cr} = 3$ and the number of levels \jp{jpk}~$= 31$, 657 the four coefficients $h_{sur}$, $h_0$, $h_1$, and $h_{th}$ in 658 \autoref{eq:DOM_zgr_ana_2} have been determined such that 659 \autoref{eq:DOM_zgr_coef} is satisfied, through an optimisation procedure using a bisection method. 660 For the first standard ORCA2 vertical grid this led to the following values: 661 $h_{sur} = 4762.96$, $h_0 = 255.58, h_1 = 245.5813$, and $h_{th} = 21.43336$. 662 The resulting depths and scale factors as a function of the model levels are shown in 663 \autoref{fig:zgr} and given in \autoref{tab:orca_zgr}. 664 Those values correspond to the parameters \np{ppsur}, \np{ppa0}, \np{ppa1}, \np{ppkth} in \ngn{namcfg} namelist. 665 666 Rather than entering parameters $h_{sur}$, $h_0$, and $h_1$ directly, it is possible to recalculate them. 667 In that case the user sets \np{ppsur}~$=$~\np{ppa0}~$=$~\np{ppa1}~$= 999999$., 668 in \ngn{namcfg} namelist, and specifies instead the four following parameters: 669 \begin{itemize} 670 \item 671 \np{ppacr}~$= h_{cr}$: stretching factor (nondimensional). 672 The larger \np{ppacr}, the smaller the stretching. 673 Values from $3$ to $10$ are usual. 674 \item 675 \np{ppkth}~$= h_{th}$: is approximately the model level at which maximum stretching occurs 676 (nondimensional, usually of order 1/2 or 2/3 of \jp{jpk}) 677 \item 678 \np{ppdzmin}: minimum thickness for the top layer (in meters). 679 \item 680 \np{pphmax}: total depth of the ocean (meters). 681 \end{itemize} 682 As an example, for the $45$ layers used in the DRAKKAR configuration those parameters are: 683 \jp{jpk}~$= 46$, \np{ppacr}~$= 9$, \np{ppkth}~$= 23.563$, \np{ppdzmin}~$= 6~m$, \np{pphmax}~$= 5750~m$. 684 685 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 686 \begin{table} 687 \begin{center} 688 \begin{tabular}{c||r|r|r|r} 689 \hline 690 \textbf{LEVEL} & \textbf{gdept\_1d} & \textbf{gdepw\_1d} & \textbf{e3t\_1d } & \textbf{e3w\_1d} \\ 691 \hline 692 1 & \textbf{ 5.00} & 0.00 & \textbf{ 10.00} & 10.00 \\ 693 \hline 694 2 & \textbf{ 15.00} & 10.00 & \textbf{ 10.00} & 10.00 \\ 695 \hline 696 3 & \textbf{ 25.00} & 20.00 & \textbf{ 10.00} & 10.00 \\ 697 \hline 698 4 & \textbf{ 35.01} & 30.00 & \textbf{ 10.01} & 10.00 \\ 699 \hline 700 5 & \textbf{ 45.01} & 40.01 & \textbf{ 10.01} & 10.01 \\ 701 \hline 702 6 & \textbf{ 55.03} & 50.02 & \textbf{ 10.02} & 10.02 \\ 703 \hline 704 7 & \textbf{ 65.06} & 60.04 & \textbf{ 10.04} & 10.03 \\ 705 \hline 706 8 & \textbf{ 75.13} & 70.09 & \textbf{ 10.09} & 10.06 \\ 707 \hline 708 9 & \textbf{ 85.25} & 80.18 & \textbf{ 10.17} & 10.12 \\ 709 \hline 710 10 & \textbf{ 95.49} & 90.35 & \textbf{ 10.33} & 10.24 \\ 711 \hline 712 11 & \textbf{ 105.97} & 100.69 & \textbf{ 10.65} & 10.47 \\ 713 \hline 714 12 & \textbf{ 116.90} & 111.36 & \textbf{ 11.27} & 10.91 \\ 715 \hline 716 13 & \textbf{ 128.70} & 122.65 & \textbf{ 12.47} & 11.77 \\ 717 \hline 718 14 & \textbf{ 142.20} & 135.16 & \textbf{ 14.78} & 13.43 \\ 719 \hline 720 15 & \textbf{ 158.96} & 150.03 & \textbf{ 19.23} & 16.65 \\ 721 \hline 722 16 & \textbf{ 181.96} & 169.42 & \textbf{ 27.66} & 22.78 \\ 723 \hline 724 17 & \textbf{ 216.65} & 197.37 & \textbf{ 43.26} & 34.30 \\ 725 \hline 726 18 & \textbf{ 272.48} & 241.13 & \textbf{ 70.88} & 55.21 \\ 727 \hline 728 19 & \textbf{ 364.30} & 312.74 & \textbf{ 116.11} & 90.99 \\ 729 \hline 730 20 & \textbf{ 511.53} & 429.72 & \textbf{ 181.55} & 146.43 \\ 731 \hline 732 21 & \textbf{ 732.20} & 611.89 & \textbf{ 261.03} & 220.35 \\ 733 \hline 734 22 & \textbf{ 1033.22} & 872.87 & \textbf{ 339.39} & 301.42 \\ 735 \hline 736 23 & \textbf{ 1405.70} & 1211.59 & \textbf{ 402.26} & 373.31 \\ 737 \hline 738 24 & \textbf{ 1830.89} & 1612.98 & \textbf{ 444.87} & 426.00 \\ 739 \hline 740 25 & \textbf{ 2289.77} & 2057.13 & \textbf{ 470.55} & 459.47 \\ 741 \hline 742 26 & \textbf{ 2768.24} & 2527.22 & \textbf{ 484.95} & 478.83 \\ 743 \hline 744 27 & \textbf{ 3257.48} & 3011.90 & \textbf{ 492.70} & 489.44 \\ 745 \hline 746 28 & \textbf{ 3752.44} & 3504.46 & \textbf{ 496.78} & 495.07 \\ 747 \hline 748 29 & \textbf{ 4250.40} & 4001.16 & \textbf{ 498.90} & 498.02 \\ 749 \hline 750 30 & \textbf{ 4749.91} & 4500.02 & \textbf{ 500.00} & 499.54 \\ 751 \hline 752 31 & \textbf{ 5250.23} & 5000.00 & \textbf{ 500.56} & 500.33 \\ 753 \hline 754 \end{tabular} 755 \end{center} 756 \caption{ 757 \protect\label{tab:orca_zgr} 758 Default vertical mesh in $z$-coordinate for 30 layers ORCA2 configuration as computed from 759 \autoref{eq:DOM_zgr_ana_2} using the coefficients given in \autoref{eq:DOM_zgr_coef} 760 } 761 \end{table} 762 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 763 764 % ------------------------------------------------------------------------------------------------------------- 765 % z-coordinate with partial step 766 % ------------------------------------------------------------------------------------------------------------- 767 \subsection{$Z$-coordinate with partial step (\protect\np{ln\_zps}~\forcode{= .true.})} 768 \label{subsec:DOM_zps} 769 %--------------------------------------------namdom------------------------------------------------------- 770 771 \nlst{namdom} 772 %-------------------------------------------------------------------------------------------------------------- 773 774 In $z$-coordinate partial step, 775 the depths of the model levels are defined by the reference analytical function $z_0(k)$ as described in 776 the previous section, \textit{except} in the bottom layer. 777 The thickness of the bottom layer is allowed to vary as a function of geographical location $(\lambda,\varphi)$ to 778 allow a better representation of the bathymetry, especially in the case of small slopes 779 (where the bathymetry varies by less than one level thickness from one grid point to the next). 780 The reference layer thicknesses $e_{3t}^0$ have been defined in the absence of bathymetry. 781 With partial steps, layers from 1 to \jp{jpk}-2 can have a thickness smaller than $e_{3t}(jk)$. 782 The model deepest layer (\jp{jpk}-1) is allowed to have either a smaller or larger thickness than $e_{3t}(jpk)$: 783 the maximum thickness allowed is $2*e_{3t}(jpk - 1)$. 784 This has to be kept in mind when specifying values in \ngn{namdom} namelist, 785 as the maximum depth \np{pphmax} in partial steps: 786 for example, with \np{pphmax}~$= 5750~m$ for the DRAKKAR 45 layer grid, 787 the maximum ocean depth allowed is actually $6000~m$ (the default thickness $e_{3t}(jpk - 1)$ being $250~m$). 788 Two variables in the namdom namelist are used to define the partial step vertical grid. 789 The mimimum water thickness (in meters) allowed for a cell partially filled with bathymetry at level jk is 790 the minimum of \np{rn\_e3zps\_min} (thickness in meters, usually $20~m$) or $e_{3t}(jk)*$\np{rn\_e3zps\_rat} 791 (a fraction, usually 10\%, of the default thickness $e_{3t}(jk)$). 792 793 \gmcomment{ \colorbox{yellow}{Add a figure here of pstep especially at last ocean level } } 794 795 % ------------------------------------------------------------------------------------------------------------- 796 % s-coordinate 797 % ------------------------------------------------------------------------------------------------------------- 798 \subsection{$S$-coordinate (\protect\np{ln\_sco}~\forcode{= .true.})} 799 \label{subsec:DOM_sco} 800 %------------------------------------------nam_zgr_sco--------------------------------------------------- 801 % 802 %\nlst{namzgr_sco} 803 %-------------------------------------------------------------------------------------------------------------- 804 Options are defined in \ngn{namzgr\_sco}. 805 In $s$-coordinate (\np{ln\_sco}~\forcode{= .true.}), the depth and thickness of the model levels are defined from 806 the product of a depth field and either a stretching function or its derivative, respectively: 807 808 \begin{align*} 809 % \label{eq:DOM_sco_ana} 810 z(k) &= h(i,j) \; z_0 (k) \\ 811 e_3(k) &= h(i,j) \; z_0'(k) 812 \end{align*} 813 814 where $h$ is the depth of the last $w$-level ($z_0(k)$) defined at the $t$-point location in the horizontal and 815 $z_0(k)$ is a function which varies from $0$ at the sea surface to $1$ at the ocean bottom. 816 The depth field $h$ is not necessary the ocean depth, 817 since a mixed step-like and bottom-following representation of the topography can be used 818 (\autoref{fig:z_zps_s_sps}) or an envelop bathymetry can be defined (\autoref{fig:z_zps_s_sps}). 819 The namelist parameter \np{rn\_rmax} determines the slope at which 820 the terrain-following coordinate intersects the sea bed and becomes a pseudo z-coordinate. 821 The coordinate can also be hybridised by specifying \np{rn\_sbot\_min} and \np{rn\_sbot\_max} as 822 the minimum and maximum depths at which the terrain-following vertical coordinate is calculated. 823 824 Options for stretching the coordinate are provided as examples, 825 but care must be taken to ensure that the vertical stretch used is appropriate for the application. 826 827 The original default NEMO s-coordinate stretching is available if neither of the other options are specified as true 828 (\np{ln\_s\_SH94}~\forcode{= .false.} and \np{ln\_s\_SF12}~\forcode{= .false.}). 829 This uses a depth independent $\tanh$ function for the stretching \citep{Madec_al_JPO96}: 830 831 \[ 832 z = s_{min} + C (s) (H - s_{min}) 833 % \label{eq:SH94_1} 834 \] 835 836 where $s_{min}$ is the depth at which the $s$-coordinate stretching starts and 837 allows a $z$-coordinate to placed on top of the stretched coordinate, 838 and $z$ is the depth (negative down from the asea surface). 839 \begin{gather*} 840 s = - \frac{k}{n - 1} \quad \text{and} \quad 0 \leq k \leq n - 1 841 % \label{eq:DOM_s} 842 \\ 843 % \label{eq:DOM_sco_function} 844 C(s) = \frac{[\tanh(\theta \, (s + b)) - \tanh(\theta \, b)]}{2 \; \sinh(\theta)} 845 \end{gather*} 846 847 A stretching function, 848 modified from the commonly used \citet{Song_Haidvogel_JCP94} stretching (\np{ln\_s\_SH94}~\forcode{= .true.}), 849 is also available and is more commonly used for shelf seas modelling: 850 851 \[ 852 C(s) = (1 - b) \frac{\sinh(\theta s)}{\sinh(\theta)} 853 + b \frac{\tanh \lt[ \theta \lt(s + \frac{1}{2} \rt) \rt] - \tanh \lt( \frac{\theta}{2} \rt)} 854 { 2 \tanh \lt( \frac{\theta}{2} \rt)} 855 % \label{eq:SH94_2} 856 \] 857 858 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 859 \begin{figure}[!ht] 860 \begin{center} 861 \includegraphics[]{Fig_sco_function} 862 \caption{ 863 \protect\label{fig:sco_function} 864 Examples of the stretching function applied to a seamount; 865 from left to right: surface, surface and bottom, and bottom intensified resolutions 866 } 867 \end{center} 868 \end{figure} 869 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 870 871 where $H_c$ is the critical depth (\np{rn\_hc}) at which the coordinate transitions from pure $\sigma$ to 872 the stretched coordinate, and $\theta$ (\np{rn\_theta}) and $b$ (\np{rn\_bb}) are the surface and 873 bottom control parameters such that $0 \leqslant \theta \leqslant 20$, and $0 \leqslant b \leqslant 1$. 874 $b$ has been designed to allow surface and/or bottom increase of the vertical resolution 875 (\autoref{fig:sco_function}). 876 877 Another example has been provided at version 3.5 (\np{ln\_s\_SF12}) that allows a fixed surface resolution in 878 an analytical terrain-following stretching \citet{Siddorn_Furner_OM12}. 879 In this case the a stretching function $\gamma$ is defined such that: 880 881 \begin{equation} 882 z = - \gamma h \quad \text{with} \quad 0 \leq \gamma \leq 1 883 % \label{eq:z} 884 \end{equation} 885 886 The function is defined with respect to $\sigma$, the unstretched terrain-following coordinate: 887 888 \begin{gather*} 889 % \label{eq:DOM_gamma_deriv} 890 \gamma = A \lt( \sigma - \frac{1}{2} (\sigma^2 + f (\sigma)) \rt) 891 + B \lt( \sigma^3 - f (\sigma) \rt) + f (\sigma) \\ 892 \intertext{Where:} 893 % \label{eq:DOM_gamma} 894 f(\sigma) = (\alpha + 2) \sigma^{\alpha + 1} - (\alpha + 1) \sigma^{\alpha + 2} 895 \quad \text{and} \quad \sigma = \frac{k}{n - 1} 896 \end{gather*} 897 898 This gives an analytical stretching of $\sigma$ that is solvable in $A$ and $B$ as a function of 899 the user prescribed stretching parameter $\alpha$ (\np{rn\_alpha}) that stretches towards 900 the surface ($\alpha > 1.0$) or the bottom ($\alpha < 1.0$) and 901 user prescribed surface (\np{rn\_zs}) and bottom depths. 902 The bottom cell depth in this example is given as a function of water depth: 903 904 \[ 905 % \label{eq:DOM_zb} 906 Z_b = h a + b 907 \] 908 909 where the namelist parameters \np{rn\_zb\_a} and \np{rn\_zb\_b} are $a$ and $b$ respectively. 910 911 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> 912 \begin{figure}[!ht] 913 \includegraphics[]{Fig_DOM_compare_coordinates_surface} 914 \caption{ 915 A comparison of the \citet{Song_Haidvogel_JCP94} $S$-coordinate (solid lines), 916 a 50 level $Z$-coordinate (contoured surfaces) and 917 the \citet{Siddorn_Furner_OM12} $S$-coordinate (dashed lines) in the surface $100~m$ for 918 a idealised bathymetry that goes from $50~m$ to $5500~m$ depth. 919 For clarity every third coordinate surface is shown. 920 } 921 \label{fig:fig_compare_coordinates_surface} 922 \end{figure} 923 % >>>>>>>>>>>>>>>>>>>>>>>>>>>> 924 925 This gives a smooth analytical stretching in computational space that is constrained to 926 given specified surface and bottom grid cell thicknesses in real space. 927 This is not to be confused with the hybrid schemes that 928 superimpose geopotential coordinates on terrain following coordinates thus 929 creating a non-analytical vertical coordinate that 930 therefore may suffer from large gradients in the vertical resolutions. 931 This stretching is less straightforward to implement than the \citet{Song_Haidvogel_JCP94} stretching, 932 but has the advantage of resolving diurnal processes in deep water and has generally flatter slopes. 933 934 As with the \citet{Song_Haidvogel_JCP94} stretching the stretch is only applied at depths greater than 935 the critical depth $h_c$. 936 In this example two options are available in depths shallower than $h_c$, 937 with pure sigma being applied if the \np{ln\_sigcrit} is true and pure z-coordinates if it is false 938 (the z-coordinate being equal to the depths of the stretched coordinate at $h_c$). 939 940 Minimising the horizontal slope of the vertical coordinate is important in terrain-following systems as 941 large slopes lead to hydrostatic consistency. 942 A hydrostatic consistency parameter diagnostic following \citet{Haney1991} has been implemented, 943 and is output as part of the model mesh file at the start of the run. 944 945 % ------------------------------------------------------------------------------------------------------------- 946 % z*- or s*-coordinate 947 % ------------------------------------------------------------------------------------------------------------- 948 \subsection{\zstar- or \sstar-coordinate (\protect\np{ln\_linssh}~\forcode{= .false.})} 949 \label{subsec:DOM_zgr_star} 950 951 This option is described in the Report by Levier \textit{et al.} (2007), available on the \NEMO web site. 952 953 %gm% key advantage: minimise the diffusion/dispertion associated with advection in response to high frequency surface disturbances 954 955 % ------------------------------------------------------------------------------------------------------------- 956 % level bathymetry and mask 957 % ------------------------------------------------------------------------------------------------------------- 958 \subsection{Level bathymetry and mask} 959 \label{subsec:DOM_msk} 960 961 Whatever the vertical coordinate used, the model offers the possibility of representing the bottom topography with 962 steps that follow the face of the model cells (step like topography) \citep{Madec_al_JPO96}. 963 The distribution of the steps in the horizontal is defined in a 2D integer array, mbathy, which 964 gives the number of ocean levels (\ie those that are not masked) at each $t$-point. 965 mbathy is computed from the meter bathymetry using the definiton of gdept as the number of $t$-points which 966 gdept $\leq$ bathy. 967 968 Modifications of the model bathymetry are performed in the \textit{bat\_ctl} routine (see \mdl{domzgr} module) after 969 mbathy is computed. 970 Isolated grid points that do not communicate with another ocean point at the same level are eliminated. 971 972 As for the representation of bathymetry, a 2D integer array, misfdep, is created. 973 misfdep defines the level of the first wet $t$-point. 974 All the cells between $k = 1$ and $misfdep(i,j) - 1$ are masked. 975 By default, $misfdep(:,:) = 1$ and no cells are masked. 976 977 In case of ice shelf cavities, modifications of the model bathymetry and ice shelf draft into 978 the cavities are performed in the \textit{zgr\_isf} routine. 979 The compatibility between ice shelf draft and bathymetry is checked. 980 All the locations where the isf cavity is thinnest than \np{rn\_isfhmin} meters are grounded (\ie masked). 981 If only one cell on the water column is opened at $t$-, $u$- or $v$-points, 982 the bathymetry or the ice shelf draft is dug to fit this constrain. 983 If the incompatibility is too strong (need to dig more than 1 cell), the cell is masked. 984 985 From the \textit{mbathy} and \textit{misfdep} array, the mask fields are defined as follows: 986 \begin{alignat*}{2} 987 tmask(i,j,k) &= & & 988 \begin{cases} 989 0 &\text{if $ k < misfdep(i,j)$} \\ 990 1 &\text{if $misfdep(i,j) \leq k \leq mbathy(i,j)$} \\ 991 0 &\text{if $ k > mbathy(i,j)$} 992 \end{cases} 993 \\ 994 umask(i,j,k) &= & &tmask(i,j,k) * tmask(i + 1,j, k) \\ 995 vmask(i,j,k) &= & &tmask(i,j,k) * tmask(i ,j + 1,k) \\ 996 fmask(i,j,k) &= & &tmask(i,j,k) * tmask(i + 1,j, k) \\ 997 & &* &tmask(i,j,k) * tmask(i + 1,j, k) \\ 998 wmask(i,j,k) &= & &tmask(i,j,k) * tmask(i ,j,k - 1) \\ 999 \text{with~} wmask(i,j,1) &= & &tmask(i,j,1) 1000 \end{alignat*} 1001 1002 Note that, without ice shelves cavities, 1003 masks at $t-$ and $w-$points are identical with the numerical indexing used (\autoref{subsec:DOM_Num_Index}). 1004 Nevertheless, $wmask$ are required with ocean cavities to deal with the top boundary (ice shelf/ocean interface) 1005 exactly in the same way as for the bottom boundary. 1006 1007 The specification of closed lateral boundaries requires that at least 1008 the first and last rows and columns of the \textit{mbathy} array are set to zero. 1009 In the particular case of an east-west cyclical boundary condition, \textit{mbathy} has its last column equal to 1010 the second one and its first column equal to the last but one (and so too the mask arrays) 1011 (see \autoref{fig:LBC_jperio}). 1012 1013 % ================================================================ 1014 % Domain: Initial State (dtatsd & istate) 1015 % ================================================================ 1016 \section{Initial state (\protect\mdl{istate} and \protect\mdl{dtatsd})} 1017 \label{sec:DTA_tsd} 1018 %-----------------------------------------namtsd------------------------------------------- 1019 1020 \nlst{namtsd} 1021 %------------------------------------------------------------------------------------------ 1022 1023 Options are defined in \ngn{namtsd}. 1024 By default, the ocean start from rest (the velocity field is set to zero) and the initialization of temperature and 1025 salinity fields is controlled through the \np{ln\_tsd\_ini} namelist parameter. 634 The user has the option to 635 set the bathymetry in closed seas to zero (see \autoref{sec:MISC_closea}) and to 636 optionally decide on the fate of any freshwater imbalance over the area. 637 The options are explained in \autoref{sec:MISC_closea} but 638 it should be noted here that a successful use of these options requires 639 appropriate mask fields to be present in the domain configuration file. 640 Among the possibilities are: 641 642 \begin{clines} 643 int closea_mask /* non-zero values in closed sea areas for optional masking */ 644 int closea_mask_rnf /* non-zero values in closed sea areas with runoff locations (precip only) */ 645 int closea_mask_emp /* non-zero values in closed sea areas with runoff locations (total emp) */ 646 \end{clines} 647 648 %% ================================================================================================= 649 \subsection{Output grid files} 650 \label{subsec:DOM_meshmask} 651 652 Most of the arrays relating to a particular ocean model configuration discussed in this chapter 653 (grid-point position, scale factors) can be saved in a file if 654 namelist parameter \np{ln_write_cfg}{ln\_write\_cfg} (namelist \nam{cfg}{cfg}) is set to 655 \forcode{.true.}; 656 the output filename is set through parameter \np{cn_domcfg_out}{cn\_domcfg\_out}. 657 This is only really useful if 658 the fields are computed in subroutines \mdl{usrdef\_hgr} or \mdl{usrdef\_zgr} and 659 checking or confirmation is required. 660 661 Alternatively, all the arrays relating to a particular ocean model configuration 662 (grid-point position, scale factors, depths and masks) can be saved in 663 a file called \texttt{mesh\_mask} if 664 namelist parameter \np{ln_meshmask}{ln\_meshmask} (namelist \nam{dom}{dom}) is set to 665 \forcode{.true.}. 666 This file contains additional fields that can be useful for post-processing applications. 667 668 %% ================================================================================================= 669 \section[Initial state (\textit{istate.F90} and \textit{dtatsd.F90})]{Initial state (\protect\mdl{istate} and \protect\mdl{dtatsd})} 670 \label{sec:DOM_DTA_tsd} 671 672 \begin{listing} 673 \nlst{namtsd} 674 \caption{\forcode{&namtsd}} 675 \label{lst:namtsd} 676 \end{listing} 677 678 Basic initial state options are defined in \nam{tsd}{tsd}. 679 By default, the ocean starts from rest (the velocity field is set to zero) and 680 the initialization of temperature and salinity fields is controlled through the \np{ln_tsd_init}{ln\_tsd\_init} namelist parameter. 681 1026 682 \begin{description} 1027 \item [\np{ln\_tsd\_init}~\forcode{= .true.}]1028 use a T and S input files that can be given on the model grid itself or on their native input data grid.683 \item [{\np[=.true.]{ln_tsd_init}{ln\_tsd\_init}}] Use T and S input files that can be given on 684 the model grid itself or on their native input data grids. 1029 685 In the latter case, 1030 686 the data will be interpolated on-the-fly both in the horizontal and the vertical to the model grid 1031 687 (see \autoref{subsec:SBC_iof}). 1032 The information relative to the input files are given in the \np{sn\_tem} and \np{sn\_sal} structures. 688 The information relating to the input files are specified in 689 the \np{sn_tem}{sn\_tem} and \np{sn_sal}{sn\_sal} structures. 1033 690 The computation is done in the \mdl{dtatsd} module. 1034 \item[\np{ln\_tsd\_init}~\forcode{= .false.}] 1035 use constant salinity value of $35.5~psu$ and an analytical profile of temperature 1036 (typical of the tropical ocean), see \rou{istate\_t\_s} subroutine called from \mdl{istate} module. 691 \item [{\np[=.false.]{ln_tsd_init}{ln\_tsd\_init}}] Initial values for T and S are set via 692 a user supplied \rou{usr\_def\_istate} routine contained in \mdl{userdef\_istate}. 693 The default version sets horizontally uniform T and profiles as used in the GYRE configuration 694 (see \autoref{sec:CFGS_gyre}). 1037 695 \end{description} 1038 696 1039 \biblio 1040 1041 \pindex 697 \subinc{\input{../../global/epilogue}} 1042 698 1043 699 \end{document} -
NEMO/branches/2019/dev_r10721_KERNEL-02_Storkey_Coward_IMMERSE_first_steps/doc/latex/NEMO/subfiles/chap_DYN.tex
r10499 r11830 2 2 3 3 \begin{document} 4 % ================================================================ 5 % Chapter ——— Ocean Dynamics (DYN) 6 % ================================================================ 4 7 5 \chapter{Ocean Dynamics (DYN)} 8 6 \label{chap:DYN} 9 7 10 \minitoc 8 \thispagestyle{plain} 9 10 \chaptertoc 11 12 \paragraph{Changes record} ~\\ 13 14 {\footnotesize 15 \begin{tabularx}{\textwidth}{l||X|X} 16 Release & Author(s) & Modifications \\ 17 \hline 18 {\em 4.0} & {\em ...} & {\em ...} \\ 19 {\em 3.6} & {\em ...} & {\em ...} \\ 20 {\em 3.4} & {\em ...} & {\em ...} \\ 21 {\em <=3.4} & {\em ...} & {\em ...} 22 \end{tabularx} 23 } 24 25 \clearpage 11 26 12 27 Using the representation described in \autoref{chap:DOM}, … … 36 51 (surface wind stress calculation using bulk formulae, estimation of mixing coefficients) 37 52 that are carried out in modules SBC, LDF and ZDF and are described in 38 \autoref{chap:SBC}, \autoref{chap:LDF} and \autoref{chap:ZDF}, respectively. 53 \autoref{chap:SBC}, \autoref{chap:LDF} and \autoref{chap:ZDF}, respectively. 39 54 40 55 In the present chapter we also describe the diagnostic equations used to compute the horizontal divergence, 41 56 curl of the velocities (\emph{divcur} module) and the vertical velocity (\emph{wzvmod} module). 42 57 43 The different options available to the user are managed by namelist variables. 44 For term \textit{ttt} in the momentum equations, the logical namelist variables are \textit{ln\_dynttt\_xxx}, 58 The different options available to the user are managed by namelist variables. 59 For term \textit{ttt} in the momentum equations, the logical namelist variables are \textit{ln\_dynttt\_xxx}, 45 60 where \textit{xxx} is a 3 or 4 letter acronym corresponding to each optional scheme. 46 If a CPP key is used for this term its name is \key{ttt}.61 %If a CPP key is used for this term its name is \key{ttt}. 47 62 The corresponding code can be found in the \textit{dynttt\_xxx} module in the DYN directory, 48 63 and it is usually computed in the \textit{dyn\_ttt\_xxx} subroutine. 49 64 50 65 The user has the option of extracting and outputting each tendency term from the 3D momentum equations 51 (\ key{trddyn} defined), as described in \autoref{chap:MISC}.52 Furthermore, the tendency terms associated with the 2D barotropic vorticity balance (when \ key{trdvor} is defined)66 (\texttt{trddyn?} defined), as described in \autoref{chap:MISC}. 67 Furthermore, the tendency terms associated with the 2D barotropic vorticity balance (when \texttt{trdvor?} is defined) 53 68 can be derived from the 3D terms. 54 %%% 55 \gmcomment{STEVEN: not quite sure I've got the sense of the last sentence. does 56 MISC correspond to "extracting tendency terms" or "vorticity balance"?} 57 58 % ================================================================ 59 % Sea Surface Height evolution & Diagnostics variables 60 % ================================================================ 69 \cmtgm{STEVEN: not quite sure I've got the sense of the last sentence. 70 Does MISC correspond to "extracting tendency terms" or "vorticity balance"?} 71 72 %% ================================================================================================= 61 73 \section{Sea surface height and diagnostic variables ($\eta$, $\zeta$, $\chi$, $w$)} 62 74 \label{sec:DYN_divcur_wzv} 63 75 64 %-------------------------------------------------------------------------------------------------------------- 65 % Horizontal divergence and relative vorticity 66 %-------------------------------------------------------------------------------------------------------------- 67 \subsection{Horizontal divergence and relative vorticity (\protect\mdl{divcur})} 76 %% ================================================================================================= 77 \subsection[Horizontal divergence and relative vorticity (\textit{divcur.F90})]{Horizontal divergence and relative vorticity (\protect\mdl{divcur})} 68 78 \label{subsec:DYN_divcur} 69 79 70 The vorticity is defined at an $f$-point (\ie corner point) as follows:71 \begin{equation} 72 \label{eq: divcur_cur}80 The vorticity is defined at an $f$-point (\ie\ corner point) as follows: 81 \begin{equation} 82 \label{eq:DYN_divcur_cur} 73 83 \zeta =\frac{1}{e_{1f}\,e_{2f} }\left( {\;\delta_{i+1/2} \left[ {e_{2v}\;v} \right] 74 84 -\delta_{j+1/2} \left[ {e_{1u}\;u} \right]\;} \right) 75 \end{equation} 85 \end{equation} 76 86 77 87 The horizontal divergence is defined at a $T$-point. 78 88 It is given by: 79 89 \[ 80 % \label{eq: divcur_div}90 % \label{eq:DYN_divcur_div} 81 91 \chi =\frac{1}{e_{1t}\,e_{2t}\,e_{3t} } 82 92 \left( {\delta_i \left[ {e_{2u}\,e_{3u}\,u} \right] … … 96 106 ensure perfect restartability. 97 107 The vorticity and divergence at the \textit{now} time step are used for the computation of 98 the nonlinear advection and of the vertical velocity respectively. 99 100 %-------------------------------------------------------------------------------------------------------------- 101 % Sea Surface Height evolution 102 %-------------------------------------------------------------------------------------------------------------- 103 \subsection{Horizontal divergence and relative vorticity (\protect\mdl{sshwzv})} 108 the nonlinear advection and of the vertical velocity respectively. 109 110 %% ================================================================================================= 111 \subsection[Horizontal divergence and relative vorticity (\textit{sshwzv.F90})]{Horizontal divergence and relative vorticity (\protect\mdl{sshwzv})} 104 112 \label{subsec:DYN_sshwzv} 105 113 106 114 The sea surface height is given by: 107 115 \begin{equation} 108 \label{eq: dynspg_ssh}116 \label{eq:DYN_spg_ssh} 109 117 \begin{aligned} 110 118 \frac{\partial \eta }{\partial t} … … 115 123 \end{aligned} 116 124 \end{equation} 117 where \textit{emp} is the surface freshwater budget (evaporation minus precipitation), 125 where \textit{emp} is the surface freshwater budget (evaporation minus precipitation), 118 126 expressed in Kg/m$^2$/s (which is equal to mm/s), 119 127 and $\rho_w$=1,035~Kg/m$^3$ is the reference density of sea water (Boussinesq approximation). 120 128 If river runoff is expressed as a surface freshwater flux (see \autoref{chap:SBC}) then 121 \textit{emp} can be written as the evaporation minus precipitation, minus the river runoff. 129 \textit{emp} can be written as the evaporation minus precipitation, minus the river runoff. 122 130 The sea-surface height is evaluated using exactly the same time stepping scheme as 123 the tracer equation \autoref{eq: tra_nxt}:131 the tracer equation \autoref{eq:TRA_nxt}: 124 132 a leapfrog scheme in combination with an Asselin time filter, 125 \ie the velocity appearing in \autoref{eq:dynspg_ssh} is centred in time (\textit{now} velocity).133 \ie\ the velocity appearing in \autoref{eq:DYN_spg_ssh} is centred in time (\textit{now} velocity). 126 134 This is of paramount importance. 127 135 Replacing $T$ by the number $1$ in the tracer equation and summing over the water column must lead to 128 136 the sea surface height equation otherwise tracer content will not be conserved 129 \citep{ Griffies_al_MWR01, Leclair_Madec_OM09}.137 \citep{griffies.pacanowski.ea_MWR01, leclair.madec_OM09}. 130 138 131 139 The vertical velocity is computed by an upward integration of the horizontal divergence starting at the bottom, 132 140 taking into account the change of the thickness of the levels: 133 141 \begin{equation} 134 \label{eq: wzv}142 \label{eq:DYN_wzv} 135 143 \left\{ 136 144 \begin{aligned} … … 142 150 \end{equation} 143 151 144 In the case of a non-linear free surface (\ key{vvl}), the top vertical velocity is $-\textit{emp}/\rho_w$,152 In the case of a non-linear free surface (\texttt{vvl?}), the top vertical velocity is $-\textit{emp}/\rho_w$, 145 153 as changes in the divergence of the barotropic transport are absorbed into the change of the level thicknesses, 146 154 re-orientated downward. 147 \ gmcomment{not sure of this... to be modified with the change in emp setting}148 In the case of a linear free surface, the time derivative in \autoref{eq: wzv} disappears.155 \cmtgm{not sure of this... to be modified with the change in emp setting} 156 In the case of a linear free surface, the time derivative in \autoref{eq:DYN_wzv} disappears. 149 157 The upper boundary condition applies at a fixed level $z=0$. 150 158 The top vertical velocity is thus equal to the divergence of the barotropic transport 151 (\ie the first term in the right-hand-side of \autoref{eq:dynspg_ssh}).159 (\ie\ the first term in the right-hand-side of \autoref{eq:DYN_spg_ssh}). 152 160 153 161 Note also that whereas the vertical velocity has the same discrete expression in $z$- and $s$-coordinates, 154 162 its physical meaning is not the same: 155 163 in the second case, $w$ is the velocity normal to the $s$-surfaces. 156 Note also that the $k$-axis is re-orientated downwards in the \fortran code compared to 157 the indexing used in the semi-discrete equations such as \autoref{eq:wzv} 158 (see \autoref{subsec:DOM_Num_Index_vertical}). 159 160 161 % ================================================================ 162 % Coriolis and Advection terms: vector invariant form 163 % ================================================================ 164 Note also that the $k$-axis is re-orientated downwards in the \fortran\ code compared to 165 the indexing used in the semi-discrete equations such as \autoref{eq:DYN_wzv} 166 (see \autoref{subsec:DOM_Num_Index_vertical}). 167 168 %% ================================================================================================= 164 169 \section{Coriolis and advection: vector invariant form} 165 170 \label{sec:DYN_adv_cor_vect} 166 %-----------------------------------------nam_dynadv---------------------------------------------------- 167 168 \nlst{namdyn_adv} 169 %------------------------------------------------------------------------------------------------------------- 171 172 \begin{listing} 173 \nlst{namdyn_adv} 174 \caption{\forcode{&namdyn_adv}} 175 \label{lst:namdyn_adv} 176 \end{listing} 170 177 171 178 The vector invariant form of the momentum equations is the one most often used in 172 applications of the \NEMO ocean model.179 applications of the \NEMO\ ocean model. 173 180 The flux form option (see next section) has been present since version $2$. 174 Options are defined through the \n gn{namdyn\_adv} namelist variables Coriolis and181 Options are defined through the \nam{dyn_adv}{dyn\_adv} namelist variables Coriolis and 175 182 momentum advection terms are evaluated using a leapfrog scheme, 176 \ie the velocity appearing in these expressions is centred in time (\textit{now} velocity).183 \ie\ the velocity appearing in these expressions is centred in time (\textit{now} velocity). 177 184 At the lateral boundaries either free slip, no slip or partial slip boundary conditions are applied following 178 185 \autoref{chap:LBC}. 179 186 180 % ------------------------------------------------------------------------------------------------------------- 181 % Vorticity term 182 % ------------------------------------------------------------------------------------------------------------- 183 \subsection{Vorticity term (\protect\mdl{dynvor})} 187 %% ================================================================================================= 188 \subsection[Vorticity term (\textit{dynvor.F90})]{Vorticity term (\protect\mdl{dynvor})} 184 189 \label{subsec:DYN_vor} 185 %------------------------------------------nam_dynvor---------------------------------------------------- 186 187 \nlst{namdyn_vor} 188 %------------------------------------------------------------------------------------------------------------- 189 190 Options are defined through the \ngn{namdyn\_vor} namelist variables. 191 Four discretisations of the vorticity term (\np{ln\_dynvor\_xxx}\forcode{ = .true.}) are available: 190 191 \begin{listing} 192 \nlst{namdyn_vor} 193 \caption{\forcode{&namdyn_vor}} 194 \label{lst:namdyn_vor} 195 \end{listing} 196 197 Options are defined through the \nam{dyn_vor}{dyn\_vor} namelist variables. 198 Four discretisations of the vorticity term (\texttt{ln\_dynvor\_xxx}\forcode{=.true.}) are available: 192 199 conserving potential enstrophy of horizontally non-divergent flow (ENS scheme); 193 200 conserving horizontal kinetic energy (ENE scheme); … … 195 202 horizontal kinetic energy for the planetary vorticity term (MIX scheme); 196 203 or conserving both the potential enstrophy of horizontally non-divergent flow and horizontal kinetic energy 197 (EEN scheme) (see \autoref{subsec: C_vorEEN}).204 (EEN scheme) (see \autoref{subsec:INVARIANTS_vorEEN}). 198 205 In the case of ENS, ENE or MIX schemes the land sea mask may be slightly modified to ensure the consistency of 199 vorticity term with analytical equations (\np {ln\_dynvor\_con}\forcode{ = .true.}).206 vorticity term with analytical equations (\np[=.true.]{ln_dynvor_con}{ln\_dynvor\_con}). 200 207 The vorticity terms are all computed in dedicated routines that can be found in the \mdl{dynvor} module. 201 208 202 %-------------------------------------------------------------203 209 % enstrophy conserving scheme 204 % -------------------------------------------------------------205 \subsubsection {Enstrophy conserving scheme (\protect\np{ln\_dynvor\_ens}\forcode{ = .true.})}210 %% ================================================================================================= 211 \subsubsection[Enstrophy conserving scheme (\forcode{ln_dynvor_ens})]{Enstrophy conserving scheme (\protect\np{ln_dynvor_ens}{ln\_dynvor\_ens})} 206 212 \label{subsec:DYN_vor_ens} 207 213 208 214 In the enstrophy conserving case (ENS scheme), 209 215 the discrete formulation of the vorticity term provides a global conservation of the enstrophy 210 ($ [ (\zeta +f ) / e_{3f} ]^2 $ in $s$-coordinates) for a horizontally non-divergent flow (\ie $\chi$=$0$),216 ($ [ (\zeta +f ) / e_{3f} ]^2 $ in $s$-coordinates) for a horizontally non-divergent flow (\ie\ $\chi$=$0$), 211 217 but does not conserve the total kinetic energy. 212 218 It is given by: 213 219 \begin{equation} 214 \label{eq: dynvor_ens}220 \label{eq:DYN_vor_ens} 215 221 \left\{ 216 222 \begin{aligned} … … 221 227 \end{aligned} 222 228 \right. 223 \end{equation} 224 225 %------------------------------------------------------------- 229 \end{equation} 230 226 231 % energy conserving scheme 227 % -------------------------------------------------------------228 \subsubsection {Energy conserving scheme (\protect\np{ln\_dynvor\_ene}\forcode{ = .true.})}232 %% ================================================================================================= 233 \subsubsection[Energy conserving scheme (\forcode{ln_dynvor_ene})]{Energy conserving scheme (\protect\np{ln_dynvor_ene}{ln\_dynvor\_ene})} 229 234 \label{subsec:DYN_vor_ene} 230 235 … … 232 237 It is given by: 233 238 \begin{equation} 234 \label{eq: dynvor_ene}239 \label{eq:DYN_vor_ene} 235 240 \left\{ 236 241 \begin{aligned} … … 241 246 \end{aligned} 242 247 \right. 243 \end{equation} 244 245 %------------------------------------------------------------- 248 \end{equation} 249 246 250 % mix energy/enstrophy conserving scheme 247 % -------------------------------------------------------------248 \subsubsection {Mixed energy/enstrophy conserving scheme (\protect\np{ln\_dynvor\_mix}\forcode{ = .true.})}251 %% ================================================================================================= 252 \subsubsection[Mixed energy/enstrophy conserving scheme (\forcode{ln_dynvor_mix})]{Mixed energy/enstrophy conserving scheme (\protect\np{ln_dynvor_mix}{ln\_dynvor\_mix})} 249 253 \label{subsec:DYN_vor_mix} 250 254 251 255 For the mixed energy/enstrophy conserving scheme (MIX scheme), a mixture of the two previous schemes is used. 252 It consists of the ENS scheme (\autoref{eq: dynvor_ens}) for the relative vorticity term,253 and of the ENE scheme (\autoref{eq: dynvor_ene}) applied to the planetary vorticity term.254 \[ 255 % \label{eq: dynvor_mix}256 It consists of the ENS scheme (\autoref{eq:DYN_vor_ens}) for the relative vorticity term, 257 and of the ENE scheme (\autoref{eq:DYN_vor_ene}) applied to the planetary vorticity term. 258 \[ 259 % \label{eq:DYN_vor_mix} 256 260 \left\{ { 257 261 \begin{aligned} … … 268 272 \] 269 273 270 %-------------------------------------------------------------271 274 % energy and enstrophy conserving scheme 272 % -------------------------------------------------------------273 \subsubsection {Energy and enstrophy conserving scheme (\protect\np{ln\_dynvor\_een}\forcode{ = .true.})}275 %% ================================================================================================= 276 \subsubsection[Energy and enstrophy conserving scheme (\forcode{ln_dynvor_een})]{Energy and enstrophy conserving scheme (\protect\np{ln_dynvor_een}{ln\_dynvor\_een})} 274 277 \label{subsec:DYN_vor_een} 275 278 … … 278 281 the presence of grid point oscillation structures that will be invisible to the operator. 279 282 These structures are \textit{computational modes} that will be at least partly damped by 280 the momentum diffusion operator (\ie the subgrid-scale advection), but not by the resolved advection term.283 the momentum diffusion operator (\ie\ the subgrid-scale advection), but not by the resolved advection term. 281 284 The ENS and ENE schemes therefore do not contribute to dump any grid point noise in the horizontal velocity field. 282 285 Such noise would result in more noise in the vertical velocity field, an undesirable feature. … … 284 287 $u$ and $v$ are located at different grid points, 285 288 a price worth paying to avoid a double averaging in the pressure gradient term as in the $B$-grid. 286 \ gmcomment{ To circumvent this, Adcroft (ADD REF HERE)289 \cmtgm{ To circumvent this, Adcroft (ADD REF HERE) 287 290 Nevertheless, this technique strongly distort the phase and group velocity of Rossby waves....} 288 291 289 A very nice solution to the problem of double averaging was proposed by \citet{ Arakawa_Hsu_MWR90}.292 A very nice solution to the problem of double averaging was proposed by \citet{arakawa.hsu_MWR90}. 290 293 The idea is to get rid of the double averaging by considering triad combinations of vorticity. 291 294 It is noteworthy that this solution is conceptually quite similar to the one proposed by 292 \citep{ Griffies_al_JPO98} for the discretization of the iso-neutral diffusion operator (see \autoref{apdx:C}).293 294 The \citet{ Arakawa_Hsu_MWR90} vorticity advection scheme for a single layer is modified295 for spherical coordinates as described by \citet{ Arakawa_Lamb_MWR81} to obtain the EEN scheme.296 First consider the discrete expression of the potential vorticity, $q$, defined at an $f$-point: 297 \[ 298 % \label{eq: pot_vor}295 \citep{griffies.gnanadesikan.ea_JPO98} for the discretization of the iso-neutral diffusion operator (see \autoref{apdx:INVARIANTS}). 296 297 The \citet{arakawa.hsu_MWR90} vorticity advection scheme for a single layer is modified 298 for spherical coordinates as described by \citet{arakawa.lamb_MWR81} to obtain the EEN scheme. 299 First consider the discrete expression of the potential vorticity, $q$, defined at an $f$-point: 300 \[ 301 % \label{eq:DYN_pot_vor} 299 302 q = \frac{\zeta +f} {e_{3f} } 300 303 \] 301 where the relative vorticity is defined by (\autoref{eq: divcur_cur}),302 the Coriolis parameter is given by $f=2 \,\Omega \;\sin \varphi _f $ and the layer thickness at $f$-points is: 303 \begin{equation} 304 \label{eq: een_e3f}304 where the relative vorticity is defined by (\autoref{eq:DYN_divcur_cur}), 305 the Coriolis parameter is given by $f=2 \,\Omega \;\sin \varphi _f $ and the layer thickness at $f$-points is: 306 \begin{equation} 307 \label{eq:DYN_een_e3f} 305 308 e_{3f} = \overline{\overline {e_{3t} }} ^{\,i+1/2,j+1/2} 306 309 \end{equation} 307 310 308 %>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>309 311 \begin{figure}[!ht] 310 \begin{center} 311 \includegraphics[width=0.70\textwidth]{Fig_DYN_een_triad} 312 \caption{ 313 \protect\label{fig:DYN_een_triad} 314 Triads used in the energy and enstrophy conserving scheme (een) for 315 $u$-component (upper panel) and $v$-component (lower panel). 316 } 317 \end{center} 312 \centering 313 \includegraphics[width=0.66\textwidth]{DYN_een_triad} 314 \caption[Triads used in the energy and enstrophy conserving scheme (EEN)]{ 315 Triads used in the energy and enstrophy conserving scheme (EEN) for 316 $u$-component (upper panel) and $v$-component (lower panel).} 317 \label{fig:DYN_een_triad} 318 318 \end{figure} 319 % >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 320 321 A key point in \autoref{eq:een_e3f} is how the averaging in the \textbf{i}- and \textbf{j}- directions is made. 319 320 A key point in \autoref{eq:DYN_een_e3f} is how the averaging in the \textbf{i}- and \textbf{j}- directions is made. 322 321 It uses the sum of masked t-point vertical scale factor divided either by the sum of the four t-point masks 323 (\np {nn\_een\_e3f}\forcode{ = 1}), or just by $4$ (\np{nn\_een\_e3f}\forcode{ = .true.}).322 (\np[=1]{nn_een_e3f}{nn\_een\_e3f}), or just by $4$ (\np[=.true.]{nn_een_e3f}{nn\_een\_e3f}). 324 323 The latter case preserves the continuity of $e_{3f}$ when one or more of the neighbouring $e_{3t}$ tends to zero and 325 324 extends by continuity the value of $e_{3f}$ into the land areas. … … 327 326 (with a systematic reduction of $e_{3f}$ when a model level intercept the bathymetry) 328 327 that tends to reinforce the topostrophy of the flow 329 (\ie the tendency of the flow to follow the isobaths) \citep{Penduff_al_OS07}.328 (\ie\ the tendency of the flow to follow the isobaths) \citep{penduff.le-sommer.ea_OS07}. 330 329 331 330 Next, the vorticity triads, $ {^i_j}\mathbb{Q}^{i_p}_{j_p}$ can be defined at a $T$-point as 332 331 the following triad combinations of the neighbouring potential vorticities defined at f-points 333 (\autoref{fig:DYN_een_triad}): 334 \begin{equation} 335 \label{eq: Q_triads}332 (\autoref{fig:DYN_een_triad}): 333 \begin{equation} 334 \label{eq:DYN_Q_triads} 336 335 _i^j \mathbb{Q}^{i_p}_{j_p} 337 336 = \frac{1}{12} \ \left( q^{i-i_p}_{j+j_p} + q^{i+j_p}_{j+i_p} + q^{i+i_p}_{j-j_p} \right) 338 337 \end{equation} 339 where the indices $i_p$ and $k_p$ take the values: $i_p = -1/2$ or $1/2$ and $j_p = -1/2$ or $1/2$. 340 341 Finally, the vorticity terms are represented as: 342 \begin{equation} 343 \label{eq: dynvor_een}338 where the indices $i_p$ and $k_p$ take the values: $i_p = -1/2$ or $1/2$ and $j_p = -1/2$ or $1/2$. 339 340 Finally, the vorticity terms are represented as: 341 \begin{equation} 342 \label{eq:DYN_vor_een} 344 343 \left\{ { 345 344 \begin{aligned} … … 350 349 \end{aligned} 351 350 } \right. 352 \end{equation} 351 \end{equation} 353 352 354 353 This EEN scheme in fact combines the conservation properties of the ENS and ENE schemes. 355 354 It conserves both total energy and potential enstrophy in the limit of horizontally nondivergent flow 356 (\ie $\chi$=$0$) (see \autoref{subsec:C_vorEEN}).355 (\ie\ $\chi$=$0$) (see \autoref{subsec:INVARIANTS_vorEEN}). 357 356 Applied to a realistic ocean configuration, it has been shown that it leads to a significant reduction of 358 the noise in the vertical velocity field \citep{ Le_Sommer_al_OM09}.357 the noise in the vertical velocity field \citep{le-sommer.penduff.ea_OM09}. 359 358 Furthermore, used in combination with a partial steps representation of bottom topography, 360 359 it improves the interaction between current and topography, 361 leading to a larger topostrophy of the flow \citep{Barnier_al_OD06, Penduff_al_OS07}. 362 363 %-------------------------------------------------------------------------------------------------------------- 364 % Kinetic Energy Gradient term 365 %-------------------------------------------------------------------------------------------------------------- 366 \subsection{Kinetic energy gradient term (\protect\mdl{dynkeg})} 360 leading to a larger topostrophy of the flow \citep{barnier.madec.ea_OD06, penduff.le-sommer.ea_OS07}. 361 362 %% ================================================================================================= 363 \subsection[Kinetic energy gradient term (\textit{dynkeg.F90})]{Kinetic energy gradient term (\protect\mdl{dynkeg})} 367 364 \label{subsec:DYN_keg} 368 365 369 As demonstrated in \autoref{apdx: C},366 As demonstrated in \autoref{apdx:INVARIANTS}, 370 367 there is a single discrete formulation of the kinetic energy gradient term that, 371 368 together with the formulation chosen for the vertical advection (see below), 372 369 conserves the total kinetic energy: 373 370 \[ 374 % \label{eq: dynkeg}371 % \label{eq:DYN_keg} 375 372 \left\{ 376 373 \begin{aligned} … … 381 378 \] 382 379 383 %-------------------------------------------------------------------------------------------------------------- 384 % Vertical advection term 385 %-------------------------------------------------------------------------------------------------------------- 386 \subsection{Vertical advection term (\protect\mdl{dynzad}) } 380 %% ================================================================================================= 381 \subsection[Vertical advection term (\textit{dynzad.F90})]{Vertical advection term (\protect\mdl{dynzad})} 387 382 \label{subsec:DYN_zad} 388 383 … … 391 386 conserves the total kinetic energy. 392 387 Indeed, the change of KE due to the vertical advection is exactly balanced by 393 the change of KE due to the gradient of KE (see \autoref{apdx: C}).394 \[ 395 % \label{eq: dynzad}388 the change of KE due to the gradient of KE (see \autoref{apdx:INVARIANTS}). 389 \[ 390 % \label{eq:DYN_zad} 396 391 \left\{ 397 392 \begin{aligned} … … 401 396 \right. 402 397 \] 403 When \np {ln\_dynzad\_zts}\forcode{ = .true.},398 When \np[=.true.]{ln_dynzad_zts}{ln\_dynzad\_zts}, 404 399 a split-explicit time stepping with 5 sub-timesteps is used on the vertical advection term. 405 This option can be useful when the value of the timestep is limited by vertical advection \citep{ Lemarie_OM2015}.400 This option can be useful when the value of the timestep is limited by vertical advection \citep{lemarie.debreu.ea_OM15}. 406 401 Note that in this case, 407 402 a similar split-explicit time stepping should be used on vertical advection of tracer to ensure a better stability, 408 an option which is only available with a TVD scheme (see \np{ln\_traadv\_tvd\_zts} in \autoref{subsec:TRA_adv_tvd}). 409 410 411 % ================================================================ 412 % Coriolis and Advection : flux form 413 % ================================================================ 403 an option which is only available with a TVD scheme (see \np{ln_traadv_tvd_zts}{ln\_traadv\_tvd\_zts} in \autoref{subsec:TRA_adv_tvd}). 404 405 %% ================================================================================================= 414 406 \section{Coriolis and advection: flux form} 415 407 \label{sec:DYN_adv_cor_flux} 416 %------------------------------------------nam_dynadv---------------------------------------------------- 417 418 \nlst{namdyn_adv} 419 %------------------------------------------------------------------------------------------------------------- 420 421 Options are defined through the \ngn{namdyn\_adv} namelist variables. 408 409 Options are defined through the \nam{dyn_adv}{dyn\_adv} namelist variables. 422 410 In the flux form (as in the vector invariant form), 423 411 the Coriolis and momentum advection terms are evaluated using a leapfrog scheme, 424 \ie the velocity appearing in their expressions is centred in time (\textit{now} velocity).412 \ie\ the velocity appearing in their expressions is centred in time (\textit{now} velocity). 425 413 At the lateral boundaries either free slip, 426 414 no slip or partial slip boundary conditions are applied following \autoref{chap:LBC}. 427 415 428 429 %-------------------------------------------------------------------------------------------------------------- 430 % Coriolis plus curvature metric terms 431 %-------------------------------------------------------------------------------------------------------------- 432 \subsection{Coriolis plus curvature metric terms (\protect\mdl{dynvor}) } 416 %% ================================================================================================= 417 \subsection[Coriolis plus curvature metric terms (\textit{dynvor.F90})]{Coriolis plus curvature metric terms (\protect\mdl{dynvor})} 433 418 \label{subsec:DYN_cor_flux} 434 419 435 420 In flux form, the vorticity term reduces to a Coriolis term in which the Coriolis parameter has been modified to account for the "metric" term. 436 421 This altered Coriolis parameter is thus discretised at $f$-points. 437 It is given by: 422 It is given by: 438 423 \begin{multline*} 439 % \label{eq: dyncor_metric}424 % \label{eq:DYN_cor_metric} 440 425 f+\frac{1}{e_1 e_2 }\left( {v\frac{\partial e_2 }{\partial i} - u\frac{\partial e_1 }{\partial j}} \right) \\ 441 426 \equiv f + \frac{1}{e_{1f} e_{2f} } \left( { \ \overline v ^{i+1/2}\delta_{i+1/2} \left[ {e_{2u} } \right] 442 427 - \overline u ^{j+1/2}\delta_{j+1/2} \left[ {e_{1u} } \right] } \ \right) 443 \end{multline*} 444 445 Any of the (\autoref{eq: dynvor_ens}), (\autoref{eq:dynvor_ene}) and (\autoref{eq:dynvor_een}) schemes can be used to428 \end{multline*} 429 430 Any of the (\autoref{eq:DYN_vor_ens}), (\autoref{eq:DYN_vor_ene}) and (\autoref{eq:DYN_vor_een}) schemes can be used to 446 431 compute the product of the Coriolis parameter and the vorticity. 447 However, the energy-conserving scheme (\autoref{eq:dynvor_een}) has exclusively been used to date. 448 This term is evaluated using a leapfrog scheme, \ie the velocity is centred in time (\textit{now} velocity). 449 450 %-------------------------------------------------------------------------------------------------------------- 451 % Flux form Advection term 452 %-------------------------------------------------------------------------------------------------------------- 453 \subsection{Flux form advection term (\protect\mdl{dynadv}) } 432 However, the energy-conserving scheme (\autoref{eq:DYN_vor_een}) has exclusively been used to date. 433 This term is evaluated using a leapfrog scheme, \ie\ the velocity is centred in time (\textit{now} velocity). 434 435 %% ================================================================================================= 436 \subsection[Flux form advection term (\textit{dynadv.F90})]{Flux form advection term (\protect\mdl{dynadv})} 454 437 \label{subsec:DYN_adv_flux} 455 438 456 439 The discrete expression of the advection term is given by: 457 440 \[ 458 % \label{eq: dynadv}441 % \label{eq:DYN_adv} 459 442 \left\{ 460 443 \begin{aligned} … … 475 458 a $2^{nd}$ order centered finite difference scheme, CEN2, 476 459 or a $3^{rd}$ order upstream biased scheme, UBS. 477 The latter is described in \citet{ Shchepetkin_McWilliams_OM05}.478 The schemes are selected using the namelist logicals \np{ln \_dynadv\_cen2} and \np{ln\_dynadv\_ubs}.460 The latter is described in \citet{shchepetkin.mcwilliams_OM05}. 461 The schemes are selected using the namelist logicals \np{ln_dynadv_cen2}{ln\_dynadv\_cen2} and \np{ln_dynadv_ubs}{ln\_dynadv\_ubs}. 479 462 In flux form, the schemes differ by the choice of a space and time interpolation to define the value of 480 $u$ and $v$ at the centre of each face of $u$- and $v$-cells, \ie at the $T$-, $f$-, 481 and $uw$-points for $u$ and at the $f$-, $T$- and $vw$-points for $v$. 482 483 %------------------------------------------------------------- 463 $u$ and $v$ at the centre of each face of $u$- and $v$-cells, \ie\ at the $T$-, $f$-, 464 and $uw$-points for $u$ and at the $f$-, $T$- and $vw$-points for $v$. 465 484 466 % 2nd order centred scheme 485 % -------------------------------------------------------------486 \subsubsection {CEN2: $2^{nd}$ order centred scheme (\protect\np{ln\_dynadv\_cen2}\forcode{ = .true.})}467 %% ================================================================================================= 468 \subsubsection[CEN2: $2^{nd}$ order centred scheme (\forcode{ln_dynadv_cen2})]{CEN2: $2^{nd}$ order centred scheme (\protect\np{ln_dynadv_cen2}{ln\_dynadv\_cen2})} 487 469 \label{subsec:DYN_adv_cen2} 488 470 489 471 In the centered $2^{nd}$ order formulation, the velocity is evaluated as the mean of the two neighbouring points: 490 472 \begin{equation} 491 \label{eq: dynadv_cen2}473 \label{eq:DYN_adv_cen2} 492 474 \left\{ 493 475 \begin{aligned} … … 496 478 \end{aligned} 497 479 \right. 498 \end{equation} 499 500 The scheme is non diffusive (\ie conserves the kinetic energy) but dispersive (\ieit may create false extrema).480 \end{equation} 481 482 The scheme is non diffusive (\ie\ conserves the kinetic energy) but dispersive (\ie\ it may create false extrema). 501 483 It is therefore notoriously noisy and must be used in conjunction with an explicit diffusion operator to 502 484 produce a sensible solution. … … 504 486 so $u$ and $v$ are the \emph{now} velocities. 505 487 506 %-------------------------------------------------------------507 488 % UBS scheme 508 % -------------------------------------------------------------509 \subsubsection {UBS: Upstream Biased Scheme (\protect\np{ln\_dynadv\_ubs}\forcode{ = .true.})}489 %% ================================================================================================= 490 \subsubsection[UBS: Upstream Biased Scheme (\forcode{ln_dynadv_ubs})]{UBS: Upstream Biased Scheme (\protect\np{ln_dynadv_ubs}{ln\_dynadv\_ubs})} 510 491 \label{subsec:DYN_adv_ubs} 511 492 … … 514 495 For example, the evaluation of $u_T^{ubs} $ is done as follows: 515 496 \begin{equation} 516 \label{eq: dynadv_ubs}497 \label{eq:DYN_adv_ubs} 517 498 u_T^{ubs} =\overline u ^i-\;\frac{1}{6} 518 499 \begin{cases} … … 522 503 \end{equation} 523 504 where $u"_{i+1/2} =\delta_{i+1/2} \left[ {\delta_i \left[ u \right]} \right]$. 524 This results in a dissipatively dominant (\ie hyper-diffusive) truncation error525 \citep{ Shchepetkin_McWilliams_OM05}.526 The overall performance of the advection scheme is similar to that reported in \citet{ Farrow1995}.505 This results in a dissipatively dominant (\ie\ hyper-diffusive) truncation error 506 \citep{shchepetkin.mcwilliams_OM05}. 507 The overall performance of the advection scheme is similar to that reported in \citet{farrow.stevens_JPO95}. 527 508 It is a relatively good compromise between accuracy and smoothness. 528 509 It is not a \emph{positive} scheme, meaning that false extrema are permitted. 529 510 But the amplitudes of the false extrema are significantly reduced over those in the centred second order method. 530 As the scheme already includes a diffusion component, it can be used without explicit lateral diffusion on momentum 531 (\ie \np{ln\_dynldf\_lap}\forcode{ = }\np{ln\_dynldf\_bilap}\forcode{ = .false.}),511 As the scheme already includes a diffusion component, it can be used without explicit lateral diffusion on momentum 512 (\ie\ \np[=]{ln_dynldf_lap}{ln\_dynldf\_lap}\np[=.false.]{ln_dynldf_bilap}{ln\_dynldf\_bilap}), 532 513 and it is recommended to do so. 533 514 534 515 The UBS scheme is not used in all directions. 535 In the vertical, the centred $2^{nd}$ order evaluation of the advection is preferred, \ie $u_{uw}^{ubs}$ and536 $u_{vw}^{ubs}$ in \autoref{eq: dynadv_cen2} are used.537 UBS is diffusive and is associated with vertical mixing of momentum. \ gmcomment{ gm pursue the516 In the vertical, the centred $2^{nd}$ order evaluation of the advection is preferred, \ie\ $u_{uw}^{ubs}$ and 517 $u_{vw}^{ubs}$ in \autoref{eq:DYN_adv_cen2} are used. 518 UBS is diffusive and is associated with vertical mixing of momentum. \cmtgm{ gm pursue the 538 519 sentence:Since vertical mixing of momentum is a source term of the TKE equation... } 539 520 540 For stability reasons, the first term in (\autoref{eq: dynadv_ubs}),521 For stability reasons, the first term in (\autoref{eq:DYN_adv_ubs}), 541 522 which corresponds to a second order centred scheme, is evaluated using the \textit{now} velocity (centred in time), 542 523 while the second term, which is the diffusion part of the scheme, 543 524 is evaluated using the \textit{before} velocity (forward in time). 544 This is discussed by \citet{ Webb_al_JAOT98} in the context of the Quick advection scheme.525 This is discussed by \citet{webb.de-cuevas.ea_JAOT98} in the context of the Quick advection scheme. 545 526 546 527 Note that the UBS and QUICK (Quadratic Upstream Interpolation for Convective Kinematics) schemes only differ by 547 528 one coefficient. 548 Replacing $1/6$ by $1/8$ in (\autoref{eq: dynadv_ubs}) leads to the QUICK advection scheme \citep{Webb_al_JAOT98}.529 Replacing $1/6$ by $1/8$ in (\autoref{eq:DYN_adv_ubs}) leads to the QUICK advection scheme \citep{webb.de-cuevas.ea_JAOT98}. 549 530 This option is not available through a namelist parameter, since the $1/6$ coefficient is hard coded. 550 531 Nevertheless it is quite easy to make the substitution in the \mdl{dynadv\_ubs} module and obtain a QUICK scheme. … … 553 534 there is also the possibility of using a $4^{th}$ order evaluation of the advective velocity as in ROMS. 554 535 This is an error and should be suppressed soon. 555 %%% 556 \gmcomment{action : this have to be done} 557 %%% 558 559 % ================================================================ 560 % Hydrostatic pressure gradient term 561 % ================================================================ 562 \section{Hydrostatic pressure gradient (\protect\mdl{dynhpg})} 536 \cmtgm{action : this have to be done} 537 538 %% ================================================================================================= 539 \section[Hydrostatic pressure gradient (\textit{dynhpg.F90})]{Hydrostatic pressure gradient (\protect\mdl{dynhpg})} 563 540 \label{sec:DYN_hpg} 564