New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
chap_misc.tex in NEMO/trunk/doc/latex/NEMO/subfiles – NEMO

source: NEMO/trunk/doc/latex/NEMO/subfiles/chap_misc.tex @ 10354

Last change on this file since 10354 was 10354, checked in by nicolasmartin, 5 years ago

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

File size: 15.4 KB
Line 
1\documentclass[../tex_main/NEMO_manual]{subfiles}
2\begin{document}
3% ================================================================
4% Chapter ---€” Miscellaneous Topics
5% ================================================================
6\chapter{Miscellaneous Topics}
7\label{chap:MISC}
8\minitoc
9
10\newpage
11$\ $\newline    % force a new ligne
12
13% ================================================================
14% Representation of Unresolved Straits
15% ================================================================
16\section{Representation of unresolved straits}
17\label{sec:MISC_strait}
18
19In climate modeling, it often occurs that a crucial connections between water masses is broken as
20the grid mesh is too coarse to resolve narrow straits.
21For example, coarse grid spacing typically closes off the Mediterranean from the Atlantic at
22the Strait of Gibraltar.
23In this case, it is important for climate models to include the effects of salty water entering the Atlantic from
24the Mediterranean.
25Likewise, it is important for the Mediterranean to replenish its supply of water from the Atlantic to
26balance the net evaporation occurring over the Mediterranean region.
27This problem occurs even in eddy permitting simulations.
28For example, in ORCA 1/4\deg several straits of the Indonesian archipelago (Ombai, Lombok...)
29are much narrow than even a single ocean grid-point.
30
31We describe briefly here the three methods that can be used in \NEMO to handle such improperly resolved straits.
32The first two consist of opening the strait by hand while ensuring that the mass exchanges through
33the strait are not too large by either artificially reducing the surface of the strait grid-cells or,
34locally increasing the lateral friction.
35In the third one, the strait is closed but exchanges of mass, heat and salt across the land are allowed.
36Note that such modifications are so specific to a given configuration that no attempt has been made to
37set them in a generic way.
38However, examples of how they can be set up is given in the ORCA 2\deg and 0.5\deg configurations.
39For example, for details of implementation in ORCA2, search: \texttt{IF( cp\_cfg == "orca" .AND. jp\_cfg == 2 )}
40
41% -------------------------------------------------------------------------------------------------------------
42%       Hand made geometry changes
43% -------------------------------------------------------------------------------------------------------------
44\subsection{Hand made geometry changes}
45\label{subsec:MISC_strait_hand}
46
47$\bullet$ reduced scale factor in the cross-strait direction to a value in better agreement with
48the true mean width of the strait (\autoref{fig:MISC_strait_hand}).
49This technique is sometime called "partially open face" or "partially closed cells".
50The key issue here is only to reduce the faces of $T$-cell
51($i.e.$ change the value of the horizontal scale factors at $u$- or $v$-point) but not the volume of the $T$-cell.
52Indeed, reducing the volume of strait $T$-cell can easily produce a numerical instability at
53that grid point that would require a reduction of the model time step.
54The changes associated with strait management are done in \mdl{domhgr},
55just after the definition or reading of the horizontal scale factors.
56
57$\bullet$ increase of the viscous boundary layer thickness by local increase of the fmask value at the coast
58(\autoref{fig:MISC_strait_hand}).
59This is done in \mdl{dommsk} together with the setting of the coastal value of fmask (see  \autoref{sec:LBC_coast}).
60
61%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
62\begin{figure}[!tbp]
63  \begin{center}
64    \includegraphics[width=0.80\textwidth]{Fig_Gibraltar}
65    \includegraphics[width=0.80\textwidth]{Fig_Gibraltar2}
66    \caption{  \protect\label{fig:MISC_strait_hand}
67      Example of the Gibraltar strait defined in a $1^{\circ} \times 1^{\circ}$ mesh.
68      \textit{Top}: using partially open cells.
69      The meridional scale factor at $v$-point is reduced on both sides of the strait to account for
70      the real width of the strait (about 20 km).
71      Note that the scale factors of the strait $T$-point remains unchanged.
72      \textit{Bottom}: using viscous boundary layers.
73      The four fmask parameters along the strait coastlines are set to a value larger than 4,
74      $i.e.$ "strong" no-slip case (see \autoref{fig:LBC_shlat}) creating a large viscous boundary layer that
75      allows a reduced transport through the strait.}
76  \end{center}
77\end{figure}
78%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
79
80
81% ================================================================
82% Closed seas
83% ================================================================
84\section{Closed seas (\protect\mdl{closea})}
85\label{sec:MISC_closea}
86
87\colorbox{yellow}{Add here a short description of the way closed seas are managed}
88
89
90% ================================================================
91% Sub-Domain Functionality
92% ================================================================
93\section{Sub-domain functionality}
94\label{sec:MISC_zoom}
95
96\subsection{Simple subsetting of input files via NetCDF attributes}
97
98The extended grids for use with the under-shelf ice cavities will result in redundant rows around Antarctica if
99the ice cavities are not active.
100A simple mechanism for subsetting input files associated with the extended domains has been implemented to
101avoid the need to maintain different sets of input fields for use with or without active ice cavities.
102The existing 'zoom' options are overly complex for this task and marked for deletion anyway.
103This alternative subsetting operates for the j-direction only and works by optionally looking for and
104using a global file attribute (named: \np{open\_ocean\_jstart}) to determine the starting j-row for input.
105The use of this option is best explained with an example:
106consider an ORCA1 configuration using the extended grid bathymetry and coordinate files:
107\vspace{-10pt}
108\ifile{eORCA1\_bathymetry\_v2}
109\ifile{eORCA1\_coordinates}
110\noindent These files define a horizontal domain of 362x332.
111Assuming the first row with open ocean wet points in the non-isf bathymetry for this set is row 42
112(Fortran indexing) then the formally correct setting for \np{open\_ocean\_jstart} is 41.
113Using this value as the first row to be read will result in a 362x292 domain which is the same size as
114the original ORCA1 domain.
115Thus the extended coordinates and bathymetry files can be used with all the original input files for ORCA1 if
116the ice cavities are not active (\np{ln\_isfcav = .false.}).
117Full instructions for achieving this are:
118
119\noindent Add the new attribute to any input files requiring a j-row offset, i.e:
120\vspace{-10pt}
121\begin{cmds}
122ncatted  -a open_ocean_jstart,global,a,d,41 eORCA1_coordinates.nc
123ncatted  -a open_ocean_jstart,global,a,d,41 eORCA1_bathymetry_v2.nc
124\end{cmds}
125 
126\noindent Add the logical switch to \ngn{namcfg} in the configuration namelist and set true:
127%--------------------------------------------namcfg--------------------------------------------------------
128
129\nlst{namcfg}
130%--------------------------------------------------------------------------------------------------------------
131
132\noindent Note the j-size of the global domain is the (extended j-size minus \np{open\_ocean\_jstart} + 1 ) and
133this must match the size of all datasets other than bathymetry and coordinates currently.
134However the option can be extended to any global, 2D and 3D, netcdf, input field by adding the:
135\vspace{-10pt}
136\begin{forlines}
137lrowattr=ln_use_jattr
138\end{forlines}
139optional argument to the appropriate \np{iom\_get} call and the \np{open\_ocean\_jstart} attribute to
140the corresponding input files.
141It remains the users responsibility to set \np{jpjdta} and \np{jpjglo} values in
142the \np{namelist\_cfg} file according to their needs.
143
144%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
145\begin{figure}[!ht]
146  \begin{center}
147    \includegraphics[width=0.90\textwidth]{Fig_LBC_zoom}
148    \caption{  \protect\label{fig:LBC_zoom}
149      Position of a model domain compared to the data input domain when the zoom functionality is used.
150    }
151  \end{center}
152\end{figure}
153%>>>>>>>>>>>>>>>>>>>>>>>>>>>>
154
155
156% ================================================================
157% Accuracy and Reproducibility
158% ================================================================
159\section{Accuracy and reproducibility (\protect\mdl{lib\_fortran})}
160\label{sec:MISC_fortran}
161
162\subsection{Issues with intrinsinc SIGN function (\protect\key{nosignedzero})}
163\label{subsec:MISC_sign}
164
165The SIGN(A, B) is the \textsc {Fortran} intrinsic function delivers the magnitude of A with the sign of B.
166For example, SIGN(-3.0,2.0) has the value 3.0.
167The problematic case is when the second argument is zero, because, on platforms that support IEEE arithmetic,
168zero is actually a signed number.
169There is a positive zero and a negative zero.
170
171In \textsc{Fortran}~90, the processor was required always to deliver a positive result for SIGN(A, B) if B was zero.
172Nevertheless, in \textsc{Fortran}~95, the processor is allowed to do the correct thing and deliver ABS(A) when
173B is a positive zero and -ABS(A) when B is a negative zero.
174This change in the specification becomes apparent only when B is of type real, and is zero,
175and the processor is capable of distinguishing between positive and negative zero,
176and B is negative real zero.
177Then SIGN delivers a negative result where, under \textsc{Fortran}~90 rules, it used to return a positive result.
178This change may be especially sensitive for the ice model,
179so we overwrite the intrinsinc function with our own function simply performing :   \\
180\verb?   IF( B >= 0.e0 ) THEN   ;   SIGN(A,B) = ABS(A)  ?    \\
181\verb?   ELSE                   ;   SIGN(A,B) =-ABS(A)     ?  \\
182\verb?   ENDIF    ? \\
183This feature can be found in \mdl{lib\_fortran} module and is effective when \key{nosignedzero} is defined.
184We use a CPP key as the overwritting of a intrinsic function can present performance issues with
185some computers/compilers.
186
187
188\subsection{MPP reproducibility}
189\label{subsec:MISC_glosum}
190
191The numerical reproducibility of simulations on distributed memory parallel computers is a critical issue.
192In particular, within NEMO global summation of distributed arrays is most susceptible to rounding errors,
193and their propagation and accumulation cause uncertainty in final simulation reproducibility on
194different numbers of processors.
195To avoid so, based on \citet{He_Ding_JSC01} review of different technics,
196we use a so called self-compensated summation method.
197The idea is to estimate the roundoff error, store it in a buffer, and then add it back in the next addition.
198
199Suppose we need to calculate $b = a_1 + a_2 + a_3$.
200The following algorithm will allow to split the sum in two
201($sum_1 = a_{1} + a_{2}$ and $b = sum_2 = sum_1 + a_3$) with exactly the same rounding errors as
202the sum performed all at once.
203\begin{align*}
204   sum_1 \ \  &= a_1 + a_2 \\
205   error_1     &= a_2 + ( a_1 - sum_1 ) \\
206   sum_2 \ \  &= sum_1 + a_3 + error_1 \\
207   error_2     &= a_3 + error_1 + ( sum_1 - sum_2 ) \\
208   b \qquad \ &= sum_2 \\
209\end{align*}
210An example of this feature can be found in \mdl{lib\_fortran} module.
211It is systematicallt used in glob\_sum function (summation over the entire basin excluding duplicated rows and
212columns due to cyclic or north fold boundary condition as well as overlap MPP areas).
213The self-compensated summation method should be used in all summation in i- and/or j-direction.
214See \mdl{closea} module for an example.
215Note also that this implementation may be sensitive to the optimization level.
216
217\subsection{MPP scalability}
218\label{subsec:MISC_mppsca}
219
220The default method of communicating values across the north-fold in distributed memory applications (\key{mpp\_mpi})
221uses a \textsc{MPI\_ALLGATHER} function to exchange values from each processing region in
222the northern row with every other processing region in the northern row.
223This enables a global width array containing the top 4 rows to be collated on every northern row processor and then
224folded with a simple algorithm.
225Although conceptually simple, this "All to All" communication will hamper performance scalability for
226large numbers of northern row processors.
227From version 3.4 onwards an alternative method is available which only performs direct "Peer to Peer" communications
228between each processor and its immediate "neighbours" across the fold line.
229This is achieved by using the default \textsc{MPI\_ALLGATHER} method during initialisation to
230help identify the "active" neighbours.
231Stored lists of these neighbours are then used in all subsequent north-fold exchanges to
232restrict exchanges to those between associated regions.
233The collated global width array for each region is thus only partially filled but is guaranteed to
234be set at all the locations actually required by each individual for the fold operation.
235This alternative method should give identical results to the default \textsc{ALLGATHER} method and
236is recommended for large values of \np{jpni}.
237The new method is activated by setting \np{ln\_nnogather} to be true ({\bf nammpp}).
238The reproducibility of results using the two methods should be confirmed for each new,
239non-reference configuration.
240
241% ================================================================
242% Model optimisation, Control Print and Benchmark
243% ================================================================
244\section{Model optimisation, control print and benchmark}
245\label{sec:MISC_opt}
246%--------------------------------------------namctl-------------------------------------------------------
247
248\nlst{namctl} 
249%--------------------------------------------------------------------------------------------------------------
250
251 \gmcomment{why not make these bullets into subsections?}
252Options are defined through the  \ngn{namctl} namelist variables.
253
254$\bullet$ Vector optimisation:
255
256\key{vectopt\_loop} enables the internal loops to collapse.
257This is very a very efficient way to increase the length of vector calculations and thus
258to speed up the model on vector computers.
259 
260% Add here also one word on NPROMA technique that has been found useless, since compiler have made significant progress during the last decade.
261 
262% Add also one word on NEC specific optimisation (Novercheck option for example)
263 
264$\bullet$ Control print %: describe here 4 things:
265
2661- \np{ln\_ctl}: compute and print the trends averaged over the interior domain in all TRA, DYN, LDF and
267ZDF modules.
268This option is very helpful when diagnosing the origin of an undesired change in model results.
269
2702- also \np{ln\_ctl} but using the nictl and njctl namelist parameters to check the source of differences between
271mono and multi processor runs.
272
273%%gm   to be removed both here and in the code
2743- last digit comparison (\np{nn\_bit\_cmp}).
275In an MPP simulation, the computation of a sum over the whole domain is performed as the summation over
276all processors of each of their sums over their interior domains.
277This double sum never gives exactly the same result as a single sum over the whole domain,
278due to truncation differences.
279The "bit comparison" option has been introduced in order to be able to check that
280mono-processor and multi-processor runs give exactly the same results.
281% THIS is to be updated with the mpp_sum_glo  introduced in v3.3
282% nn_bit_cmp  today only check that the nn_cla = 0 (no cross land advection)
283%%gm end
284
285$\bullet$  Benchmark (\np{nn\_bench}).
286This option defines a benchmark run based on a GYRE configuration (see \autoref{sec:CFG_gyre}) in which
287the resolution remains the same whatever the domain size.
288This allows a very large model domain to be used, just by changing the domain size (\jp{jpiglo}, \jp{jpjglo}) and
289without adjusting either the time-step or the physical parameterisations.
290
291% ================================================================
292\end{document}
293
294
295
296
Note: See TracBrowser for help on using the repository browser.