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