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 @ 11597

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

Continuation of coding rules application
Recovery of some sections deleted by the previous commit

File size: 21.9 KB
Line 
1\documentclass[../main/NEMO_manual]{subfiles}
2
3\begin{document}
4\chapter{Miscellaneous Topics}
5\label{chap:MISC}
6
7\chaptertoc
8
9%% =================================================================================================
10\section{Representation of unresolved straits}
11\label{sec:MISC_strait}
12
13In climate modeling, it often occurs that a crucial connections between water masses is broken as
14the grid mesh is too coarse to resolve narrow straits.
15For example, coarse grid spacing typically closes off the Mediterranean from the Atlantic at
16the Strait of Gibraltar.
17In this case, it is important for climate models to include the effects of salty water entering the Atlantic from
18the Mediterranean.
19Likewise, it is important for the Mediterranean to replenish its supply of water from the Atlantic to
20balance the net evaporation occurring over the Mediterranean region.
21This problem occurs even in eddy permitting simulations.
22For example, in ORCA 1/4\deg\ several straits of the Indonesian archipelago (Ombai, Lombok...)
23are much narrow than even a single ocean grid-point.
24
25We describe briefly here the two methods that can be used in \NEMO\ to handle such
26improperly resolved straits. The methods consist of opening the strait while ensuring
27that the mass exchanges through the strait are not too large by either artificially
28reducing the cross-sectional area of the strait grid-cells or, locally increasing the
29lateral friction.
30
31%% =================================================================================================
32\subsection{Hand made geometry changes}
33\label{subsec:MISC_strait_hand}
34
35The first method involves reducing the scale factor in the cross-strait direction to a
36value in better agreement with the true mean width of the strait
37(\autoref{fig:MISC_strait_hand}).  This technique is sometime called "partially open face"
38or "partially closed cells".  The key issue here is only to reduce the faces of $T$-cell
39(\ie\ change the value of the horizontal scale factors at $u$- or $v$-point) but not the
40volume of the $T$-cell.  Indeed, reducing the volume of strait $T$-cell can easily produce
41a numerical instability at that grid point which would require a reduction of the model
42time step.  Thus to instigate a local change in the width of a Strait requires two steps:
43
44\begin{itemize}
45
46\item Add \texttt{e1e2u} and \texttt{e1e2v} arrays to the \np{cn_domcfg}{cn\_domcfg} file. These 2D
47arrays should contain the products of the unaltered values of: $\texttt{e1u}*\texttt{e2u}$
48and $\texttt{e1u}*\texttt{e2v}$ respectively. That is the original surface areas of $u$-
49and $v$- cells respectively.  These areas are usually defined by the corresponding product
50within the \NEMO\ code but the presence of \texttt{e1e2u} and \texttt{e1e2v} in the
51\np{cn_domcfg}{cn\_domcfg} file will suppress this calculation and use the supplied fields instead.
52If the model domain is provided by user-supplied code in \mdl{usrdef\_hgr}, then this
53routine should also return \texttt{e1e2u} and \texttt{e1e2v} and set the integer return
54argument \texttt{ie1e2u\_v} to a non-zero value. Values other than 0 for this argument
55will suppress the calculation of the areas.
56
57\item Change values of \texttt{e2u} or \texttt{e1v} (either in the \np{cn_domcfg}{cn\_domcfg} file or
58via code in  \mdl{usrdef\_hgr}), whereever a Strait reduction is required. The choice of
59whether to alter \texttt{e2u} or \texttt{e1v} depends. respectively,  on whether the
60Strait in question is North-South orientated (\eg\ Gibraltar) or East-West orientated (\eg
61Lombok).
62
63\end{itemize}
64
65The second method is to increase the viscous boundary layer thickness by a local increase
66of the fmask value at the coast. This method can also be effective in wider passages.  The
67concept is illustarted in the second part of  \autoref{fig:MISC_strait_hand} and changes
68to specific locations can be coded in \mdl{usrdef\_fmask}. The \forcode{usr_def_fmask}
69routine is always called after \texttt{fmask} has been defined according to the choice of
70lateral boundary condition as discussed in \autoref{sec:LBC_coast}. The default version of
71\mdl{usrdef\_fmask} contains settings specific to ORCA2 and ORCA1 configurations. These are
72meant as examples only; it is up to the user to verify settings and provide alternatives
73for their own configurations. The default \forcode{usr_def_fmask} makes no changes to
74\texttt{fmask} for any other configuration.
75
76\begin{figure}[!tbp]
77  \centering
78  \includegraphics[width=0.66\textwidth]{Fig_Gibraltar}
79  \includegraphics[width=0.66\textwidth]{Fig_Gibraltar2}
80  \caption[Two methods to defined the Gibraltar strait]{
81    Example of the Gibraltar strait defined in a 1\deg\ $\times$ 1\deg\ mesh.
82    \textit{Top}: using partially open cells.
83    The meridional scale factor at $v$-point is reduced on both sides of the strait to
84    account for the real width of the strait (about 20 km).
85    Note that the scale factors of the strait $T$-point remains unchanged.
86    \textit{Bottom}: using viscous boundary layers.
87    The four fmask parameters along the strait coastlines are set to a value larger than 4,
88    \ie\ "strong" no-slip case (see \autoref{fig:LBC_shlat}) creating a large viscous boundary layer
89    that allows a reduced transport through the strait.}
90  \label{fig:MISC_strait_hand}
91\end{figure}
92
93\begin{figure}[!tbp]
94  \centering
95  \includegraphics[width=0.66\textwidth]{Fig_closea_mask_example}
96  \caption[Mask fields for the \protect\mdl{closea} module]{
97    Example of mask fields for the \protect\mdl{closea} module.
98    \textit{Left}: a closea\_mask field;
99    \textit{Right}: a closea\_mask\_rnf field.
100    In this example, if \protect\np{ln_closea}{ln\_closea} is set to \forcode{.true.},
101    the mean freshwater flux over each of the American Great Lakes will be set to zero,
102    and the total residual for all the lakes, if negative, will be put into
103    the St Laurence Seaway in the area shown.}
104  \label{fig:MISC_closea_mask_example}
105\end{figure}
106
107%% =================================================================================================
108\section[Closed seas (\textit{closea.F90})]{Closed seas (\protect\mdl{closea})}
109\label{sec:MISC_closea}
110
111Some configurations include inland seas and lakes as ocean
112points. This is particularly the case for configurations that are
113coupled to an atmosphere model where one might want to include inland
114seas and lakes as ocean model points in order to provide a better
115bottom boundary condition for the atmosphere. However there is no
116route for freshwater to run off from the lakes to the ocean and this
117can lead to large drifts in the sea surface height over the lakes. The
118closea module provides options to either fill in closed seas and lakes
119at run time, or to set the net surface freshwater flux for each lake
120to zero and put the residual flux into the ocean.
121
122Prior to \NEMO\ 4 the locations of inland seas and lakes was set via
123hardcoded indices for various ORCA configurations. From \NEMO\ 4 onwards
124the inland seas and lakes are defined using mask fields in the
125domain configuration file. The options are as follows.
126
127\begin{enumerate}
128\item {{\bfseries No ``closea\_mask'' field is included in domain configuration
129  file.} In this case the closea module does nothing.}
130
131\item {{\bfseries A field called closea\_mask is included in the domain
132configuration file and ln\_closea=.false. in namelist namcfg.} In this
133case the inland seas defined by the closea\_mask field are filled in
134(turned to land points) at run time. That is every point in
135closea\_mask that is nonzero is set to be a land point.}
136
137\item {{\bfseries A field called closea\_mask is included in the domain
138configuration file and ln\_closea=.true. in namelist namcfg.} Each
139inland sea or group of inland seas is set to a positive integer value
140in the closea\_mask field (see \autoref{fig:MISC_closea_mask_example}
141for an example). The net surface flux over each inland sea or group of
142inland seas is set to zero each timestep and the residual flux is
143distributed over the global ocean (ie. all ocean points where
144closea\_mask is zero).}
145
146\item {{\bfseries Fields called closea\_mask and closea\_mask\_rnf are
147included in the domain configuration file and ln\_closea=.true. in
148namelist namcfg.} This option works as for option 3, except that if
149the net surface flux over an inland sea is negative (net
150precipitation) it is put into the ocean at specified runoff points. A
151net positive surface flux (net evaporation) is still spread over the
152global ocean. The mapping from inland seas to runoff points is defined
153by the closea\_mask\_rnf field. Each mapping is defined by a positive
154integer value for the inland sea(s) and the corresponding runoff
155points. An example is given in
156\autoref{fig:MISC_closea_mask_example}. If no mapping is provided for a
157particular inland sea then the residual is spread over the global
158ocean.}
159
160\item {{\bfseries Fields called closea\_mask and closea\_mask\_emp are
161included in the domain configuration file and ln\_closea=.true. in
162namelist namcfg.} This option works the same as option 4 except that
163the nonzero net surface flux is sent to the ocean at the specified
164runoff points regardless of whether it is positive or negative. The
165mapping from inland seas to runoff points in this case is defined by
166the closea\_mask\_emp field.}
167\end{enumerate}
168
169There is a python routine to create the closea\_mask fields and append
170them to the domain configuration file in the utils/tools/DOMAINcfg directory.
171
172%% =================================================================================================
173\section{Sub-domain functionality}
174\label{sec:MISC_zoom}
175
176%% =================================================================================================
177\subsection{Simple subsetting of input files via NetCDF attributes}
178
179The extended grids for use with the under-shelf ice cavities will result in redundant rows
180around Antarctica if the ice cavities are not active.  A simple mechanism for subsetting
181input files associated with the extended domains has been implemented to avoid the need to
182maintain different sets of input fields for use with or without active ice cavities.  This
183subsetting operates for the j-direction only and works by optionally looking for and using
184a global file attribute (named: \np{open_ocean_jstart}{open\_ocean\_jstart}) to determine the starting j-row
185for input.  The use of this option is best explained with an example:
186\medskip
187
188\noindent Consider an ORCA1
189configuration using the extended grid domain configuration file: \ifile{eORCA1\_domcfg.nc}
190This file define a horizontal domain of 362x332.  The first row with
191open ocean wet points in the non-isf bathymetry for this set is row 42 (\fortran\ indexing)
192then the formally correct setting for \np{open_ocean_jstart}{open\_ocean\_jstart} is 41.  Using this value as
193the first row to be read will result in a 362x292 domain which is the same size as the
194original ORCA1 domain.  Thus the extended domain configuration file can be used with all
195the original input files for ORCA1 if the ice cavities are not active (\np{ln\_isfcav =
196.false.}).  Full instructions for achieving this are:
197
198\begin{itemize}
199\item Add the new attribute to any input files requiring a j-row offset, i.e:
200\begin{cmds}
201ncatted  -a open_ocean_jstart,global,a,d,41 eORCA1_domcfg.nc
202\end{cmds}
203
204\item Add the logical switch \np{ln_use_jattr}{ln\_use\_jattr} to \nam{cfg}{cfg} in the configuration
205namelist (if it is not already there) and set \forcode{.true.}
206\end{itemize}
207
208\noindent Note that with this option, the j-size of the global domain is (extended
209j-size minus \np{open_ocean_jstart}{open\_ocean\_jstart} + 1 ) and this must match the \texttt{jpjglo} value
210for the configuration. This means an alternative version of \ifile{eORCA1\_domcfg.nc} must
211be created for when \np{ln_use_jattr}{ln\_use\_jattr} is active. The \texttt{ncap2} tool provides a
212convenient way of achieving this:
213
214\begin{cmds}
215ncap2 -s 'jpjglo=292' eORCA1_domcfg.nc nORCA1_domcfg.nc
216\end{cmds}
217
218The domain configuration file is unique in this respect since it also contains the value of \jp{jpjglo}
219that is read and used by the model.
220Any other global, 2D and 3D, netcdf, input field can be prepared for use in a reduced domain by adding the
221\texttt{open\_ocean\_jstart} attribute to the file's global attributes.
222In particular this is true for any field that is read by \NEMO\ using the following optional argument to
223the appropriate call to \np{iom_get}{iom\_get}.
224
225\begin{forlines}
226lrowattr=ln_use_jattr
227\end{forlines}
228
229Currently, only the domain configuration variables make use of this optional argument so
230this facility is of little practical use except for tests where no other external input
231files are needed or you wish to use an extended domain configuration with inputs from
232earlier, non-extended configurations. Alternatively, it should be possible to exclude
233empty rows for extended domain, forced ocean runs using interpolation on the fly, by
234adding the optional argument to \texttt{iom\_get} calls for the weights and initial
235conditions. Experimenting with this remains an exercise for the user.
236
237%% =================================================================================================
238\section[Accuracy and reproducibility (\textit{lib\_fortran.F90})]{Accuracy and reproducibility (\protect\mdl{lib\_fortran})}
239\label{sec:MISC_fortran}
240
241%% =================================================================================================
242\subsection[Issues with intrinsinc SIGN function (\texttt{\textbf{key\_nosignedzero}})]{Issues with intrinsinc SIGN function (\protect\key{nosignedzero})}
243\label{subsec:MISC_sign}
244
245The SIGN(A, B) is the \fortran\ intrinsic function delivers the magnitude of A with the sign of B.
246For example, SIGN(-3.0,2.0) has the value 3.0.
247The problematic case is when the second argument is zero, because, on platforms that support IEEE arithmetic,
248zero is actually a signed number.
249There is a positive zero and a negative zero.
250
251In \fninety, the processor was required always to deliver a positive result for SIGN(A, B) if B was zero.
252Nevertheless, in \fninety, the processor is allowed to do the correct thing and deliver ABS(A) when
253B is a positive zero and -ABS(A) when B is a negative zero.
254This change in the specification becomes apparent only when B is of type real, and is zero,
255and the processor is capable of distinguishing between positive and negative zero,
256and B is negative real zero.
257Then SIGN delivers a negative result where, under \fninety\ rules, it used to return a positive result.
258This change may be especially sensitive for the ice model,
259so we overwrite the intrinsinc function with our own function simply performing :   \\
260\verb?   IF( B >= 0.e0 ) THEN   ;   SIGN(A,B) = ABS(A)  ?    \\
261\verb?   ELSE                   ;   SIGN(A,B) =-ABS(A)     ?  \\
262\verb?   ENDIF    ? \\
263This feature can be found in \mdl{lib\_fortran} module and is effective when \key{nosignedzero} is defined.
264We use a CPP key as the overwritting of a intrinsic function can present performance issues with
265some computers/compilers.
266
267%% =================================================================================================
268\subsection{MPP reproducibility}
269\label{subsec:MISC_glosum}
270
271The numerical reproducibility of simulations on distributed memory parallel computers is a critical issue.
272In particular, within \NEMO\ global summation of distributed arrays is most susceptible to rounding errors,
273and their propagation and accumulation cause uncertainty in final simulation reproducibility on
274different numbers of processors.
275To avoid so, based on \citet{he.ding_JS01} review of different technics,
276we use a so called self-compensated summation method.
277The idea is to estimate the roundoff error, store it in a buffer, and then add it back in the next addition.
278
279Suppose we need to calculate $b = a_1 + a_2 + a_3$.
280The following algorithm will allow to split the sum in two
281($sum_1 = a_{1} + a_{2}$ and $b = sum_2 = sum_1 + a_3$) with exactly the same rounding errors as
282the sum performed all at once.
283\begin{align*}
284   sum_1 \ \  &= a_1 + a_2 \\
285   error_1     &= a_2 + ( a_1 - sum_1 ) \\
286   sum_2 \ \  &= sum_1 + a_3 + error_1 \\
287   error_2     &= a_3 + error_1 + ( sum_1 - sum_2 ) \\
288   b \qquad \ &= sum_2 \\
289\end{align*}
290An example of this feature can be found in \mdl{lib\_fortran} module.
291It is systematicallt used in glob\_sum function (summation over the entire basin excluding duplicated rows and
292columns due to cyclic or north fold boundary condition as well as overlap MPP areas).
293The self-compensated summation method should be used in all summation in i- and/or j-direction.
294See \mdl{closea} module for an example.
295Note also that this implementation may be sensitive to the optimization level.
296
297%% =================================================================================================
298\subsection{MPP scalability}
299\label{subsec:MISC_mppsca}
300
301The default method of communicating values across the north-fold in distributed memory applications (\key{mpp\_mpi})
302uses a \textsc{MPI\_ALLGATHER} function to exchange values from each processing region in
303the northern row with every other processing region in the northern row.
304This enables a global width array containing the top 4 rows to be collated on every northern row processor and then
305folded with a simple algorithm.
306Although conceptually simple, this "All to All" communication will hamper performance scalability for
307large numbers of northern row processors.
308From version 3.4 onwards an alternative method is available which only performs direct "Peer to Peer" communications
309between each processor and its immediate "neighbours" across the fold line.
310This is achieved by using the default \textsc{MPI\_ALLGATHER} method during initialisation to
311help identify the "active" neighbours.
312Stored lists of these neighbours are then used in all subsequent north-fold exchanges to
313restrict exchanges to those between associated regions.
314The collated global width array for each region is thus only partially filled but is guaranteed to
315be set at all the locations actually required by each individual for the fold operation.
316This alternative method should give identical results to the default \textsc{ALLGATHER} method and
317is recommended for large values of \np{jpni}{jpni}.
318The new method is activated by setting \np{ln_nnogather}{ln\_nnogather} to be true (\nam{mpp}{mpp}).
319The reproducibility of results using the two methods should be confirmed for each new,
320non-reference configuration.
321
322%% =================================================================================================
323\section{Model optimisation, control print and benchmark}
324\label{sec:MISC_opt}
325
326\begin{listing}
327  \nlst{namctl}
328  \caption{\forcode{&namctl}}
329  \label{lst:namctl}
330\end{listing}
331
332Options are defined through the  \nam{ctl}{ctl} namelist variables.
333
334%% =================================================================================================
335\subsection{Vector optimisation}
336
337\key{vectopt\_loop} enables the internal loops to collapse.
338This is very a very efficient way to increase the length of vector calculations and thus
339to speed up the model on vector computers.
340
341% Add here also one word on NPROMA technique that has been found useless, since compiler have made significant progress during the last decade.
342
343% Add also one word on NEC specific optimisation (Novercheck option for example)
344
345%% =================================================================================================
346\subsection{Control print}
347
348The \np{ln_ctl}{ln\_ctl} switch was originally used as a debugging option in two modes:
349
350\begin{enumerate}
351\item {\np{ln_ctl}{ln\_ctl}: compute and print the trends averaged over the interior domain in all TRA, DYN, LDF and
352ZDF modules.
353This option is very helpful when diagnosing the origin of an undesired change in model results. }
354
355\item {also \np{ln_ctl}{ln\_ctl} but using the nictl and njctl namelist parameters to check the source of differences between
356mono and multi processor runs.}
357\end{enumerate}
358
359However, in recent versions it has also been used to force all processors to assume the
360reporting role. Thus when \np{ln_ctl}{ln\_ctl} is true all processors produce their own versions
361of files such as: ocean.output, layout.dat, etc.  All such files, beyond the the normal
362reporting processor (narea == 1), are named with a \_XXXX extension to their name, where
363XXXX is a 4-digit area number (with leading zeros, if required). Other reporting files
364such as run.stat (and its netCDF counterpart: run.stat.nc) and tracer.stat contain global
365information and are only ever produced by the reporting master (narea == 1). For version
3664.0 a start has been made to return \np{ln_ctl}{ln\_ctl} to its original function by introducing
367a new control structure which allows finer control over which files are produced. This
368feature is still evolving but it does already allow the user to: select individually the
369production of run.stat and tracer.stat files and to toggle the production of other files
370on processors other than the reporting master. These other reporters can be a simple
371subset of processors as defined by a minimum, maximum and incremental processor number.
372
373Note, that production of the run.stat and tracer.stat files require global communications.
374For run.stat, these are global min and max operations to find metrics such as the gloabl
375maximum velocity. For tracer.stat these are global sums of tracer fields. To improve model
376performance these operations are disabled by default and, where necessary, any use of the
377global values have been replaced with local calculations. For example, checks on the CFL
378criterion are now done on the local domain and only reported if a breach is detected.
379
380Experienced users may wish to still monitor this information as a check on model progress.
381If so, the best compromise will be to activate the files with:
382
383\begin{verbatim}
384     sn_cfctl%l_config = .TRUE.
385       sn_cfctl%l_runstat = .TRUE.
386       sn_cfctl%l_trcstat = .TRUE.
387\end{verbatim}
388
389and to use the new time increment setting to ensure the values are collected and reported
390at a suitably long interval. For example:
391
392\begin{verbatim}
393       sn_cfctl%ptimincr  = 25
394\end{verbatim}
395
396will carry out the global communications and write the information every 25 timesteps. This
397increment also applies to the time.step file which is otherwise updated every timestep.
398
Note: See TracBrowser for help on using the repository browser.