Changeset 9019 for branches/2017/dev_merge_2017/DOC/TexFiles
- Timestamp:
- 2017-12-13T15:58:53+01:00 (6 years ago)
- Location:
- branches/2017/dev_merge_2017/DOC/TexFiles
- Files:
-
- 7 edited
-
Chapters/Chap_CFG.tex (modified) (6 diffs)
-
Chapters/Chap_DOM.tex (modified) (6 diffs)
-
Chapters/Chap_MISC.tex (modified) (3 diffs)
-
Chapters/Chap_SBC.tex (modified) (1 diff)
-
Chapters/Chap_ZDF.tex (modified) (2 diffs)
-
Chapters/Introduction.tex (modified) (1 diff)
-
Top_Matter.tex (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Chap_CFG.tex
r7705 r9019 25 25 in the code, though by no means are all options exercised in the reference configurations. 26 26 27 Configuration is defined mainly through the \ngn{namcfg} namelist variables:28 \sfcomment {Here change namcfg part of namelist. Configuration is defined throughout domain\_cfg.nc file now}29 30 27 %------------------------------------------namcfg---------------------------------------------------- 31 28 \namdisplay{namcfg} … … 37 34 \section{Water column model: 1D model (C1D) (\key{c1d}) } 38 35 \label{CFG_c1d} 36 37 $\ $\newline 38 BE careful: to be re-written according to suppression of jpizoom and jpjzoom !!!! 39 $\ $\newline 39 40 40 41 The 1D model option simulates a stand alone water column within the 3D \NEMO system. … … 85 86 the LIM sea-ice model (ORCA-LIM) and possibly with PISCES biogeochemical model 86 87 (ORCA-LIM-PISCES), using various resolutions. 87 The appropriate namelist is available in \textit{CONFIG/ORCA2\_LIM3\_PISCES/EXP00/namelist\_cfg} 88 for ORCA2 and in \textit{CONFIG/SHARED/README\_configs\_namcfg\_namdom} \sfcomment {not really true, they are obsolete namelists, where find these informations?} 89 for other resolutions 90 88 An appropriate namelist is available in \textit{CONFIG/ORCA2\_LIM3\_PISCES/EXP00/namelist\_cfg} 89 for ORCA2. 90 The domain of ORCA2 configuration is defined in ORCA\_R2\_zps\_domcfg.nc file, this file is available in tar file in the wiki of NEMO : \\ 91 https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ReferenceConfigurations/ORCA2\_LIM3\_PISCES \\ 92 In this namelist\_cfg the name of domain input file is set in \ngn{namcfg} block of namelist. 91 93 92 94 %>>>>>>>>>>>>>>>>>>>>>>>>>>>> … … 140 142 than the smallest one in the southern hemisphere. 141 143 The resulting mesh is shown in Fig.~\ref{Fig_MISC_ORCA_msh} and \ref{Fig_MISC_ORCA_e1e2} 142 for a half a degree grid (ORCA\_R05). The smallest ocean scale factor is found in along143 Antarctica, while the ratio of anisotropy remains close to one except near the Victoria Island144 for a half a degree grid (ORCA\_R05). 145 The smallest ocean scale factor is found in along Antarctica, while the ratio of anisotropy remains close to one except near the Victoria Island 144 146 in the Canadian Archipelago. 145 147 … … 153 155 The NEMO system is provided with five built-in ORCA configurations which differ in the 154 156 horizontal resolution. The value of the resolution is given by the resolution at the Equator 155 expressed in degrees. Each of configuration is set through the \textit{domain\_cfg} file, 156 which sets the grid size and configuration name parameters \sfcomment {I would like to change tab_ORCA but I can not find it, wrong jp_cfg} 157 (Tab. \ref{Tab_ORCA}). 157 expressed in degrees. Each of configuration is set through the \textit{domain\_cfg} domain configuration file, 158 which sets the grid size and configuration name parameters. The NEMO System Team provides only ORCA2 domain input file "ORCA\_R2\_zps\_domcfg.nc" file (Tab. \ref{Tab_ORCA}). 158 159 159 160 … … 175 176 \end{tabular} 176 177 \caption{ \label{Tab_ORCA} 177 Set of predefined parameters forORCA family configurations.178 In all cases, the flag for configurations of ORCA family is set to 1 in \textit{domain\_cfg}}178 Domain size of ORCA family configurations. 179 The flag for configurations of ORCA family need to be set in \textit{domain\_cfg} file. } 179 180 \end{center} 180 181 \end{table} -
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Chap_DOM.tex
r7705 r9019 268 268 269 269 The total size of the computational domain is set by the parameters \np{jpiglo}, 270 \np{jpjglo} and \np{jpkglo} in the $i$, $j$ and $k$ directions respectively. They are 271 given as namelist variables in the \ngn{namcfg} namelist. 270 \np{jpjglo} and \np{jpkglo} in the $i$, $j$ and $k$ directions respectively. 272 271 %%% 273 272 %%% … … 278 277 279 278 $\ $\newline % force a new line 280 281 %%%282 \sfcomment {Hereafter I want to create new subsection 4.2: "fields needed by opa engine or something like this"283 and add list of fields :284 case 1: read in domain.nc285 case 2: defined in userdef\_hrg\/zgr.F90286 longitude, latitude, domaine size287 number of points288 factor scales (e1, e2, e3)289 coriolis290 k\_top, k\_bottom (first and last ocean level)291 periodicity292 }293 %%%294 279 295 280 % ================================================================ … … 303 288 The grid-points are located at integer or integer and a half values of as indicated 304 289 in Table~\ref{Tab_cell}. The associated scale factors are defined using the 305 analytical first derivative of the transformation \eqref{Eq_scale_factors}. These 306 definitions are done in two modules given by example, \mdl{userdef\_hgr} and \mdl{userdef\_zgr}, which 307 provide the horizontal and vertical meshes, respectively. Otherwise all needed fields can be read in file \np{cn\_domcfg} specified in \ngn{namcfg}. 290 analytical first derivative of the transformation \eqref{Eq_scale_factors}. 291 Necessary fields for configuration definition are: \\ 292 Geographic position : 293 294 longitude : glamt , glamu , glamv and glamf (at T, U, V and F point) 295 296 latitude : gphit , gphiu , gphiv and gphif (at T, U, V and F point)\\ 297 Coriolis parameter (if domain not on the sphere): 298 299 ff\_f and ff\_t (at T and F point)\\ 300 Scale factors : 308 301 309 The needed fields for domain are: 310 311 geographic position : 312 313 longitude : glamt , glamu , glamv and glamf (at T, U, V and F point) 314 315 latitude : gphit , gphiu , gphiv and gphif (at T, U, V and F point) 316 317 Coriolis parameter (if domain not on the sphere): ff\_f and ff\_t (at T and F point) 318 319 Scale factors : e1t, e1u, e1v and e1f (on i direction), 320 321 e2t, e2u, e2v and e2f (on j direction) 322 323 and ie1e2u\_v, e1e2u , e1e2v 324 325 %%% 326 \sfcomment { 327 say something about ie1e2u\_v, e1e2u , e1e2v 328 329 and add list of fields : 330 case 1: read in domain.nc 331 case 2: defined in userdef\_hrg\/zgr.F90 332 longitude, latitude, domaine size 333 number of points 334 factor scales (e1, e2, e3) 335 coriolis 336 k\_top, k\_bottom (first and last ocean level) 337 periodicity 338 ---- 339 int ORCA ; 340 int ORCA\_index ; 341 int jpiglo ; j, k 342 int jperio ; 343 int ln_zco ; zps, sco 344 int ln_isfcav ; 345 double glamt(t, y, x) ; u,v,f 346 double gphit(t, y, x) ; u,v,f 347 double e1t(t, y, x) ; u,v,w, 348 double e2t(t, y, x) ; u,v,w 349 double ff\_f(t, y, x) ; double ff\_t(t, y, x) ; 350 double e3t\_1d(t, z) ; 351 double e3w\_1d(t, z) ; 352 double e3t\_0(t, z, y, x) ; u0, v0 , w0 353 ---- 354 } 355 302 e1t, e1u, e1v and e1f (on i direction), 303 304 e2t, e2u, e2v and e2f (on j direction) 305 306 and ie1e2u\_v, e1e2u , e1e2v 307 308 e1e2u , e1e2v are u and v surfaces (if gridsize reduction in some straits)\\ 309 ie1e2u\_v is a flag to flag set u and v surfaces are neither read nor computed.\\ 310 311 These fields can be read in an domain input file which name is setted in \np{cn\_domcfg} parameter specified in \ngn{namcfg}. 312 \namdisplay{namcfg} 313 or they can be defined in an analytical way in MY\_SRC directory of the configuration. 314 For Reference Configurations of NEMO input domain files are supplied by NEMO System Team. For analytical definition of input fields two routines are supplied: \mdl{userdef\_hgr} and \mdl{userdef\_zgr}. They are an example of GYRE configuration parameters, and they are available in NEMO/OPA\_SRC/USR directory, they provide the horizontal and vertical mesh. 356 315 % ------------------------------------------------------------------------------------------------------------- 357 316 % Needed fields … … 446 405 \label{DOM_hgr_msh_choice} 447 406 448 The user has three options available in defining a horizontal grid, which involve449 the namelist variable \np{jphgr\_mesh} of the \ngn{namcfg} namelist.450 \begin{description}451 \item[\np{jphgr\_mesh}=0] The most general curvilinear orthogonal grids.452 The coordinates and their first derivatives with respect to $i$ and $j$ are provided453 in a input file (\ifile{coordinates}), read in \rou{hgr\_read} subroutine of the domhgr module.454 \item[\np{jphgr\_mesh}=1 to 5] A few simple analytical grids are provided (see below).455 For other analytical grids, the \mdl{domhgr} module must be modified by the user.456 \end{description}457 458 There are two simple cases of geographical grids on the sphere. With459 \np{jphgr\_mesh}=1, the grid (expressed in degrees) is regular in space,460 with grid sizes specified by parameters \np{ppe1\_deg} and \np{ppe2\_deg},461 respectively. Such a geographical grid can be very anisotropic at high latitudes462 because of the convergence of meridians (the zonal scale factors $e_1$463 become much smaller than the meridional scale factors $e_2$). The Mercator464 grid (\np{jphgr\_mesh}=4) avoids this anisotropy by refining the meridional scale465 factors in the same way as the zonal ones. In this case, meridional scale factors466 and latitudes are calculated analytically using the formulae appropriate for467 a Mercator projection, based on \np{ppe1\_deg} which is a reference grid spacing468 at the equator (this applies even when the geographical equator is situated outside469 the model domain).470 %%%471 \gmcomment{ give here the analytical expression of the Mercator mesh}472 %%%473 In these two cases (\np{jphgr\_mesh}=1 or 4), the grid position is defined by the474 longitude and latitude of the south-westernmost point (\np{ppglamt0}475 and \np{ppgphi0}). Note that for the Mercator grid the user need only provide476 an approximate starting latitude: the real latitude will be recalculated analytically,477 in order to ensure that the equator corresponds to line passing through $t$-478 and $u$-points.479 480 Rectangular grids ignoring the spherical geometry are defined with481 \np{jphgr\_mesh} = 2, 3, 5. The domain is either an $f$-plane (\np{jphgr\_mesh} = 2,482 Coriolis factor is constant) or a beta-plane (\np{jphgr\_mesh} = 3, the Coriolis factor483 is linear in the $j$-direction). The grid size is uniform in meter in each direction,484 and given by the parameters \np{ppe1\_m} and \np{ppe2\_m} respectively.485 The zonal grid coordinate (\textit{glam} arrays) is in kilometers, starting at zero486 with the first $t$-point. The meridional coordinate (gphi. arrays) is in kilometers,487 and the second $t$-point corresponds to coordinate $gphit=0$. The input488 variable \np{ppglam0} is ignored. \np{ppgphi0} is used to set the reference489 latitude for computation of the Coriolis parameter. In the case of the beta plane,490 \np{ppgphi0} corresponds to the center of the domain. Finally, the special case491 \np{jphgr\_mesh}=5 corresponds to a beta plane in a rotated domain for the492 GYRE configuration, representing a classical mid-latitude double gyre system.493 The rotation allows us to maximize the jet length relative to the gyre areas494 (and the number of grid points).495 496 The choice of the grid must be consistent with the boundary conditions specified497 by \np{jperio}, a parameter found in \ngn{namcfg} namelist (see {\S\ref{LBC}).498 407 499 408 % ------------------------------------------------------------------------------------------------------------- … … 684 593 (Fig.~\ref{Fig_zgr}). 685 594 686 If the ice shelf cavities are opened (\np{ln\_isfcav}=~true~ }), the definition of $z_0$ is the same.595 If the ice shelf cavities are opened (\np{ln\_isfcav}=~true~), the definition of $z_0$ is the same. 687 596 However, definition of $e_3^0$ at $t$- and $w$-points is respectively changed to: 688 597 \begin{equation} \label{DOM_zgr_ana} … … 737 646 \begin{table} \begin{center} \begin{tabular}{c||r|r|r|r} 738 647 \hline 739 \textbf{LEVEL}& \textbf{gdept }& \textbf{gdepw}& \textbf{e3t }& \textbf{e3w} \\ \hline648 \textbf{LEVEL}& \textbf{gdept\_1d}& \textbf{gdepw\_1d}& \textbf{e3t\_1d }& \textbf{e3w\_1d } \\ \hline 740 649 1 & \textbf{ 5.00} & 0.00 & \textbf{ 10.00} & 10.00 \\ \hline 741 650 2 & \textbf{15.00} & 10.00 & \textbf{ 10.00} & 10.00 \\ \hline -
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Chap_MISC.tex
r7646 r9019 2 2 \begin{document} 3 3 % ================================================================ 4 % Chapter ———Miscellaneous Topics4 % Chapter --- Miscellaneous Topics 5 5 % ================================================================ 6 6 \chapter{Miscellaneous Topics} … … 87 87 88 88 % ================================================================ 89 % Sub-Domain Functionality (\textit{nizoom, njzoom}, namelist parameters)90 % ================================================================ 91 \section{Sub-Domain Functionality (\np{jpizoom}, \np{jpjzoom})}89 % Sub-Domain Functionality 90 % ================================================================ 91 \section{Sub-Domain Functionality} 92 92 \label{MISC_zoom} 93 94 The sub-domain functionality, also improperly called the zoom option95 (improperly because it is not associated with a change in model resolution)96 is a quite simple function that allows a simulation over a sub-domain of an97 already defined configuration ($i.e.$ without defining a new mesh, initial98 state and forcings). This option can be useful for testing the user settings99 of surface boundary conditions, or the initial ocean state of a huge ocean100 model configuration while having a small computer memory requirement.101 It can also be used to easily test specific physics in a sub-domain (for example,102 see \citep{Madec_al_JPO96} for a test of the coupling used in the global ocean103 version of OPA between sea-ice and ocean model over the Arctic or Antarctic104 ocean, using a sub-domain). In the standard model, this option does not105 include any specific treatment for the ocean boundaries of the sub-domain:106 they are considered as artificial vertical walls. Nevertheless, it is quite easy107 to add a restoring term toward a climatology in the vicinity of such boundaries108 (see \S\ref{TRA_dmp}).109 110 In order to easily define a sub-domain over which the computation can be111 performed, the dimension of all input arrays (ocean mesh, bathymetry,112 forcing, initial state, ...) are defined as \np{jpidta}, \np{jpjdta} and \np{jpkdta}113 ( in \ngn{namcfg} namelist), while the computational domain is defined through114 \np{jpiglo}, \np{jpjglo} and \jp{jpk} (\ngn{namcfg} namelist). When running the115 model over the whole domain, the user sets \np{jpiglo}=\np{jpidta} \np{jpjglo}=\np{jpjdta}116 and \jp{jpk}=\jp{jpkdta}. When running the model over a sub-domain, the user117 has to provide the size of the sub-domain, (\np{jpiglo}, \np{jpjglo}, \np{jpkglo}),118 and the indices of the south western corner as \np{jpizoom} and \np{jpjzoom} in119 the \ngn{namcfg} namelist (Fig.~\ref{Fig_LBC_zoom}).120 121 Note that a third set of dimensions exist, \jp{jpi}, \jp{jpj} and \jp{jpk} which is122 actually used to perform the computation. It is set by default to \jp{jpi}=\np{jpjglo}123 and \jp{jpj}=\np{jpjglo}, except for massively parallel computing where the124 computational domain is laid out on local processor memories following a 2D125 horizontal splitting. % (see {\S}IV.2-c) ref to the section to be updated126 93 127 94 \subsection{Simple subsetting of input files via netCDF attributes} … … 165 132 \noindent Add the logical switch to \ngn{namcfg} in the configuration namelist and set true: 166 133 %--------------------------------------------namcfg-------------------------------------------------------- 167 \namdisplay{namcfg _orca1}134 \namdisplay{namcfg} 168 135 %-------------------------------------------------------------------------------------------------------------- 169 136 -
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Chap_SBC.tex
r7646 r9019 1266 1266 ice-ocean fluxes, that are combined with the air-sea fluxes using the ice fraction of 1267 1267 each model cell to provide the surface ocean fluxes. Note that the activation of a 1268 sea-ice model is is done by defining a CPP key (\key{lim 2}, \key{lim3} or \key{cice}).1268 sea-ice model is is done by defining a CPP key (\key{lim3} or \key{cice}). 1269 1269 The activation automatically overwrites the read value of nn{\_}ice to its appropriate 1270 value ($i.e.$ $2$ for LIM- 2, $3$ for LIM-3 or $4$ for CICE).1270 value ($i.e.$ $2$ for LIM-3 or $3$ for CICE). 1271 1271 \end{description} 1272 1272 -
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Chap_ZDF.tex
r6997 r9019 612 612 Examples of performance of the 4 turbulent closure scheme can be found in \citet{Warner_al_OM05}. 613 613 614 % ------------------------------------------------------------------------------------------------------------- 615 % OSM OSMOSIS BL Scheme 616 % ------------------------------------------------------------------------------------------------------------- 617 \subsection{OSM OSMOSIS Boundary Layer scheme (\key{zdfosm})} 618 \label{ZDF_osm} 619 620 %--------------------------------------------namzdf_osm--------------------------------------------------------- 621 \namdisplay{namzdf_osm} 622 %-------------------------------------------------------------------------------------------------------------- 623 624 The OSMOSIS turbulent closure scheme is based on...... TBC 614 625 615 626 % ================================================================ … … 734 745 % Turbulent Closure Scheme 735 746 % ------------------------------------------------------------------------------------------------------------- 736 \subsection{Turbulent Closure Scheme (\key{zdftke} or \key{zdfgls})}747 \subsection{Turbulent Closure Scheme (\key{zdftke}, \key{zdfgls} or \key{zdfosm})} 737 748 \label{ZDF_tcs} 738 749 -
branches/2017/dev_merge_2017/DOC/TexFiles/Chapters/Introduction.tex
r6997 r9019 255 255 $\bullet$ The main modifications from NEMO/OPA v3.4 and v3.6 are :\\ 256 256 \begin{enumerate} 257 \item ... ; 258 \end{enumerate} 259 260 261 \vspace{1cm} 262 $\bullet$ The main modifications from NEMO/OPA v3.6 and v4.0 are :\\ 263 \begin{enumerate} 264 \item new definition of configurations ; 265 \item bulk formulation ; 257 266 \item ... ; 258 267 \end{enumerate} 259 268 260 269 261 \vspace{1cm}262 $\bullet$ The main modifications from NEMO/OPA v3.6 and v4.0 are :\\263 \begin{enumerate}264 \item ... ;265 266 267 \end{enumerate}268 269 270 270 \end{document} -
branches/2017/dev_merge_2017/DOC/TexFiles/Top_Matter.tex
r7646 r9019 17 17 %\date{\today} 18 18 \date{ 19 January2017 \\19 Decembre 2017 \\ 20 20 {\small -- version 4.0 alpha --} \\ 21 21 ~ \\
Note: See TracChangeset
for help on using the changeset viewer.
