Changeset 11723
- Timestamp:
- 2019-10-18T14:33:36+02:00 (5 years ago)
- Files:
-
- 4 deleted
- 7 edited
- 1 moved
Legend:
- Unmodified
- Added
- Removed
-
NEMO/trunk/CHANGES.rst
r11713 r11723 1 ******* ******2 Release Notes3 ******* ******1 ******* 2 Changes 3 ******* 4 4 5 5 .. todo:: 6 6 7 Complete "Release Notes"7 List the main additions of the the new release -
NEMO/trunk/INSTALL.rst
r11708 r11723 10 10 11 11 | The NEMO source code is written in *Fortran 95* and 12 some of its prerequisite tools and libraries are already included in the ``./ext`` subdirectory.12 some of its prerequisite tools and libraries are already included in the download. 13 13 | It contains the AGRIF_ preprocessing program ``conv``; the FCM_ build system and 14 14 the IOIPSL_ library for parts of the output. … … 40 40 This will limit MPI features to those defined within the MPI-2 standard 41 41 (but will lose some performance benefits). 42 43 Specifics for NetCDF and HDF44 ----------------------------45 46 NetCDF and HDF versions from .47 However access to all the options available with the XIOS IO-server will require48 the parallel IO support of these libraries which can be unavailable.49 50 | **To satisfy these requirements, it is common to have to compile from source51 in this order HDF (C library) then NetCDF (C and Fortran libraries)**52 | It is also necessary to compile these libraries with the same version of the MPI implementation that53 both NEMO and XIOS (see below) are compiled and linked with.54 55 .. hint::56 57 | It is difficult to define the options for the compilation as58 they differ from one architecture to another according to59 the hardware used and the software installed.60 | The following is provided without any warranty61 62 .. code-block:: console63 64 $ ./configure [--{enable-fortran,disable-shared,enable-parallel}] ...65 66 It is recommended to build the tests ``--enable-parallel-tests`` and run them with ``make check``67 68 Particular versions of these libraries may have their own restrictions.69 State the following requirements for netCDF-4 support:70 71 .. caution::72 73 | When building NetCDF-C library versions older than 4.4.1, use only HDF5 1.8.x versions.74 | Combining older NetCDF-C versions with newer HDF5 1.10 versions will create superblock 3 files75 that are not readable by lots of older software.76 77 Extract and install XIOS78 ========================79 80 With the sole exception of running NEMO in mono-processor mode81 (in which case output options are limited to those supported by the ``IOIPSL`` library),82 diagnostic outputs from NEMO are handled by the third party ``XIOS`` library.83 This can be used in two different modes:84 85 - *attached* - Every NEMO process also acts as a XIOS server86 - *detached* - Every NEMO process runs as a XIOS client.87 Output is collected and collated by external, stand-alone XIOS server processors.88 89 .. important::90 91 In either case, XIOS needs to be compiled before NEMO,92 since the libraries are needed to successfully create the NEMO executable.93 94 Instructions on how to obtain and install the software can be found on the :xios:`XIOS wiki<wiki>`.95 96 .. hint::97 98 It is recommended to use XIOS version 2.5.99 This version should be more stable (in terms of future code changes) than the XIOS trunk.100 It is also the version used by the NEMO system team when testing all developments and new releases.101 102 This particular version has its own branch and can be checked out and downloaded with:103 104 .. code:: console105 106 $ svn co https://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/branchs/xios-2.5107 108 Download the NEMO source code109 =============================110 111 .. code:: console112 113 $ svn co https://forge.ipsl.jussieu.fr/nemo/svn/NEMO/trunk114 115 Description of directory tree116 -----------------------------117 118 +-----------+------------------------------------------------------------+119 | Folder | Purpose |120 +===========+============================================================+121 | ``arch`` | Settings (per architecture-compiler pair) |122 +-----------+------------------------------------------------------------+123 | ``cfgs`` | :doc:`Reference configurations <configurations>` |124 +-----------+------------------------------------------------------------+125 | ``doc`` | - ``latex`` : LaTex source code for ref. manuals |126 | | - ``namelists``: k start guide |127 | | - ``rst`` : ReST files for quick start guide |128 +-----------+------------------------------------------------------------+129 | ``ext`` | Dependencies included (``AGRIF``, ``FCM`` & ``IOIPSL``) |130 +-----------+------------------------------------------------------------+131 | ``mk`` | Building routines |132 +-----------+------------------------------------------------------------+133 | ``src`` | Modelling routines |134 | | |135 | | - ``ICE``: |NEMO-ICE| for sea ice |136 | | - ``NST``: AGRIF for embedded zooms |137 | | - ``OCE``: |NEMO-OCE| for ocean dynamics |138 | | - ``TOP``: |NEMO-MBG| for tracers |139 +-----------+------------------------------------------------------------+140 | ``tests`` | :doc:`Test cases <test_cases>` (unsupported) |141 +-----------+------------------------------------------------------------+142 | ``tools`` | :doc:`Utilities <tools>` to [pre|post]process data |143 +-----------+------------------------------------------------------------+144 145 Setup your architecture configuration file146 ==========================================147 148 All compiler options in NEMO are controlled using files in149 ``./arch/arch-'my_arch'.fcm`` where 'my_arch' is the name of the computing150 architecture. It is recommended to copy and rename an configuration file from151 an architecture similar to your owns. You will need to set appropriate values152 for all of the variables in the file. In particular the FCM variables:153 ``%NCDF_HOME``; ``%HDF5_HOME`` and ``%XIOS_HOME`` should be set to the154 installation directories used for XIOS installation.155 156 .. code-block:: sh157 158 %NCDF_HOME /opt/local159 %HDF5_HOME /opt/local160 %XIOS_HOME /Users/$( whoami )/xios-2.5161 %OASIS_HOME /not/defined162 163 Compile and create NEMO executable164 ==================================165 166 The main script to compile and create executable is called makenemo and located in the CONFIG directory, it is used to identify the routines you need from the source code, to build the makefile and run it.167 As an example, compile GYRE with 'my_arch' to create a 'MY_GYRE' configuration:168 169 .. code-block:: sh170 171 ./makenemo –m 'my_arch' –r GYRE -n 'MY_GYRE'172 173 The image below shows the structure and some content of "MY_CONFIG" directory from the launching of the configuration creation (directories and fundamental files created by makenemo).174 175 +------------+----------------------------------------------------+176 | Folder | Purpose |177 +============+====================================================+178 | ``BLD`` | |179 +------------+----------------------------------------------------+180 | ``EXP00`` | |181 +------------+----------------------------------------------------+182 | ``EXPREF`` | |183 +------------+----------------------------------------------------+184 | ``MY_SRC`` | |185 +------------+----------------------------------------------------+186 | ``WORK`` | |187 +------------+----------------------------------------------------+188 189 Folder with the symbolic links to all unpreprocessed routines considered in the configuration190 Compilation folder (executables, headers files, libraries, preprocessed routines, flags, …)191 Computation folder for running the model (namelists, xml, executables and inputs-outputs)192 Folder intended to contain your customised routines (modified from initial ones or new entire routines)193 194 After successful execution of makenemo command, the executable called opa is created in the EXP00 directory (in the example above, the executable is created in CONFIG/MY_GYRE/EXP00).195 196 More makenemo options197 ---------------------198 199 ``makenemo`` has several other options that can control which source files are selected and200 the operation of the build process itself.201 These are::202 203 Optional:204 -d Set of new sub-components (space separated list from ./src directory)205 -e Path for alternative patch location (default: 'MY_SRC' in configuration folder)206 -h Print this help207 -j Number of processes to compile (0: no build)208 -n Name for new configuration209 -s Path for alternative source location (default: 'src' root directory)210 -t Path for alternative build location (default: 'BLD' in configuration folder)211 -v Level of verbosity ([0-3])212 213 These options can be useful for maintaining several code versions with only minor differences but214 they should be used sparingly.215 Note however the ``-j`` option which should be used more routinely to speed up the build process.216 For example:217 218 .. code-block:: sh219 220 ./makenemo –m 'my_arch' –r GYRE -n 'MY_GYRE' -j 8221 222 which will compile up to 8 modules simultaneously.223 224 225 Default behaviour226 -----------------227 228 At the first use, you need the -m option to specify the architecture229 configuration file (compiler and its options, routines and libraries to230 include), then for next compilation, it is assumed you will be using the231 same compiler. If the –n option is not specified the last compiled configuration232 will be used.233 234 Tools used during the process235 -----------------------------236 237 * functions.sh : bash functions used by makenemo, for instance to create the WORK directory238 * cfg.txt : text list of configurations and source directories239 * bld.cfg : FCM rules to compile240 241 Examples242 --------243 244 .. code-block:: sh245 246 echo "Example to install a new configuration MY_CONFIG";247 echo "with OPA_SRC and LIM_SRC_2 ";248 echo "makenemo -n MY_CONFIG -d \"OPA_SRC LIM_SRC_2\"";249 echo "";250 echo "Available configurations :"; cat ${CONFIG_DIR}/cfg.txt;251 echo "";252 echo "Available unsupported (external) configurations :"; cat ${CONFIG_DIR}/uspcfg.txt;253 echo "";254 echo "Example to remove bad configuration ";255 echo "./makenemo -n MY_CONFIG clean_config";256 echo "";257 echo "Example to clean ";258 echo "./makenemo clean";259 echo "";260 echo "Example to list the available keys of a CONFIG ";261 echo "./makenemo list_key";262 echo "";263 echo "Example to add and remove keys";264 echo "./makenemo add_key \"key_iomput key_mpp_mpi\" del_key \"key_agrif\" ";265 echo "";266 echo "Example to add and remove keys for a new configuration, and do not compile";267 echo "./makenemo -n MY_CONFIG -j0 add_key \"key_iomput key_mpp_mpi\" del_key \"key_agrif\" ";268 269 Running the model270 =================271 272 Once makenemo has run successfully, the opa executable is available in ``CONFIG/MY_CONFIG/EXP00``273 For the reference configurations, the EXP00 folder also contains the initial input files (namelists, \*xml files for the IOs…). If the configuration also needs NetCDF input files, this should be downloaded here from the corresponding tar file, see Users/Reference Configurations274 275 .. code-block:: sh276 277 cd 'MY_CONFIG'/EXP00278 mpirun -n $NPROCS ./opa # $NPROCS is the number of processes ; mpirun is your MPI wrapper279 280 281 Viewing and changing list of active CPP keys282 ============================================283 284 For a given configuration (here called MY_CONFIG), the list of active CPP keys can be found in:285 286 .. code-block:: sh287 288 ./cfgs/'MYCONFIG'/cpp_'MY_CONFIG'.fcm289 290 291 This text file can be edited to change the list of active CPP keys. Once changed, one needs to recompile opa executable using makenemo command in order for this change to be taken in account.292 Note that most NEMO configurations will need to specify the following CPP keys:293 ``key_iomput`` and ``key_mpp_mpi``294 295 .. Links and substitutions296 42 297 43 .. |OpenMPI| replace:: *OpenMPI* … … 300 46 .. _MPICH: https://www.mpich.org 301 47 .. |NetCDF| replace:: *Network Common Data Form (NetCDF)* 302 .. _NetCDF: https://www.unidata.ucar.edu /downloads/netcdf48 .. _NetCDF: https://www.unidata.ucar.edu 303 49 .. |HDF| replace:: *Hierarchical Data Form (HDF)* 304 .. _HDF: https://www.hdfgroup.org/downloads 50 .. _HDF: https://www.hdfgroup.org 51 52 Specifics for NetCDF and HDF 53 ---------------------------- 54 55 NetCDF and HDF versions from official repositories may have not been compiled with MPI support. 56 However access to all the options available with the XIOS IO-server will require 57 the parallelism of these libraries. 58 59 | **To satisfy these requirements, it is common to have to compile from source 60 in this order HDF (C library) then NetCDF (C and Fortran libraries)** 61 | It is also necessary to compile these libraries with the same version of the MPI implementation that 62 both NEMO and XIOS (see below) have been compiled and linked with. 63 64 .. hint:: 65 66 | It is difficult to define the options for the compilation as 67 they differ from one architecture to another according to 68 the hardware used and the software installed. 69 | The following is provided without any warranty 70 71 .. code-block:: console 72 73 $ ./configure [--{enable-fortran,disable-shared,enable-parallel}] ... 74 75 It is recommended to build the tests ``--enable-parallel-tests`` and run them with ``make check`` 76 77 Particular versions of these libraries may have their own restrictions. 78 State the following requirements for netCDF-4 support: 79 80 .. caution:: 81 82 | When building NetCDF-C library versions older than 4.4.1, use only HDF5 1.8.x versions. 83 | Combining older NetCDF-C versions with newer HDF5 1.10 versions will create superblock 3 files 84 that are not readable by lots of older software. 85 86 Extract and install XIOS 87 ======================== 88 89 With the sole exception of running NEMO in mono-processor mode 90 (in which case output options are limited to those supported by the ``IOIPSL`` library), 91 diagnostic outputs from NEMO are handled by the third party ``XIOS`` library. 92 It can be used in two different modes: 93 94 :*attached*: Every NEMO process also acts as a XIOS server 95 :*detached*: Every NEMO process runs as a XIOS client. 96 Output is collected and collated by external, stand-alone XIOS server processors. 97 98 Instructions on how to install XIOS can be found on its :xios:`wiki<>`. 99 100 .. hint:: 101 102 It is recommended to use XIOS 2.5 release. 103 This version should be more stable (in terms of future code changes) than the XIOS trunk. 104 It is also the one used by the NEMO system team when testing all developments and new releases. 105 106 This particular version has its own branch and can be checked out with: 107 108 .. code:: console 109 110 $ svn co https://forge.ipsl.jussieu.fr/ioserver/svn/XIOS/branchs/xios-2.5 111 112 Download and install the NEMO code 113 ================================== 114 115 Checkout the NEMO sources 116 ------------------------- 117 118 .. code:: console 119 120 $ svn co https://forge.ipsl.jussieu.fr/nemo/svn/NEMO/trunk 121 122 Description of 1\ :sup:`st` level tree structure 123 ------------------------------------------------ 124 125 +-----------+----------------------------------------+ 126 | ``arch`` | Compilation settings | 127 +-----------+----------------------------------------+ 128 | ``cfgs`` | :doc:`Reference configurations <cfgs>` | 129 +-----------+----------------------------------------+ 130 | ``doc`` | :doc:`Documentation <doc>` | 131 +-----------+----------------------------------------+ 132 | ``ext`` | Dependencies included | 133 | | (``AGRIF``, ``FCM`` & ``IOIPSL``) | 134 +-----------+----------------------------------------+ 135 | ``mk`` | Compilation scripts | 136 +-----------+----------------------------------------+ 137 | ``src`` | :doc:`Modelling routines <src>` | 138 +-----------+----------------------------------------+ 139 | ``tests`` | :doc:`Test cases <tests>` | 140 | | (unsupported) | 141 +-----------+----------------------------------------+ 142 | ``tools`` | :doc:`Utilities <tools>` | 143 | | to {pre,post}process data | 144 +-----------+----------------------------------------+ 145 146 Setup your architecture configuration file 147 ------------------------------------------ 148 149 All compiler options in NEMO are controlled using files in :file:`./arch/arch-'my_arch'.fcm` where 150 ``my_arch`` is the name of the computing architecture 151 (generally following the pattern ``HPCC-compiler`` or ``OS-compiler``). 152 It is recommended to copy and rename an configuration file from an architecture similar to your owns. 153 You will need to set appropriate values for all of the variables in the file. 154 In particular the FCM variables: 155 ``%NCDF_HOME``; ``%HDF5_HOME`` and ``%XIOS_HOME`` should be set to 156 the installation directories used for XIOS installation 157 158 .. code-block:: sh 159 160 %NCDF_HOME /usr/local/path/to/netcdf 161 %HDF5_HOME /usr/local/path/to/hdf5 162 %XIOS_HOME /home/$( whoami )/path/to/xios-2.5 163 %OASIS_HOME /home/$( whoami )/path/to/oasis 164 165 Create and compile a new configuration 166 ====================================== 167 168 The main script to {re}compile and create executable is called ``makenemo`` located at 169 the root of the working copy. 170 It is used to identify the routines you need from the source code, to build the makefile and run it. 171 As an example, compile a :file:`MY_GYRE` configuration from GYRE with 'my_arch': 172 173 .. code-block:: sh 174 175 ./makenemo –m 'my_arch' –r GYRE -n 'MY_GYRE' 176 177 Then at the end of the configuration compilation, 178 :file:`MY_GYRE` directory will have the following structure. 179 180 +------------+----------------------------------------------------------------------------+ 181 | Directory | Purpose | 182 +============+============================================================================+ 183 | ``BLD`` | BuiLD folder: target executable, headers, libs, preprocessed routines, ... | 184 +------------+----------------------------------------------------------------------------+ 185 | ``EXP00`` | Run folder: link to executable, namelists, ``*.xml`` and IOs | 186 +------------+----------------------------------------------------------------------------+ 187 | ``EXPREF`` | Files under version control only for :doc:`official configurations <cfgs>` | 188 +------------+----------------------------------------------------------------------------+ 189 | ``MY_SRC`` | New routines or modified copies of NEMO sources | 190 +------------+----------------------------------------------------------------------------+ 191 | ``WORK`` | Links to all raw routines from :file:`./src` considered | 192 +------------+----------------------------------------------------------------------------+ 193 194 After successful execution of ``makenemo`` command, 195 the executable called `nemo` is available in the :file:`EXP00` directory 196 197 More ``makenemo`` options 198 ------------------------- 199 200 ``makenemo`` has several other options that can control which source files are selected and 201 the operation of the build process itself. 202 203 .. literalinclude:: ../../../makenemo 204 :language: text 205 :lines: 119-143 206 :caption: Output of ``makenemo -h`` 207 208 These options can be useful for maintaining several code versions with only minor differences but 209 they should be used sparingly. 210 Note however the ``-j`` option which should be used more routinely to speed up the build process. 211 For example: 212 213 .. code-block:: sh 214 215 ./makenemo –m 'my_arch' –r GYRE -n 'MY_GYRE' -j 8 216 217 will compile up to 8 processes simultaneously. 218 219 Default behaviour 220 ----------------- 221 222 At the first use, 223 you need the ``-m`` option to specify the architecture configuration file 224 (compiler and its options, routines and libraries to include), 225 then for next compilation, it is assumed you will be using the same compiler. 226 If the ``-n`` option is not specified the last compiled configuration will be used. 227 228 Tools used during the process 229 ----------------------------- 230 231 * ``functions.sh`` : bash functions used by ``makenemo``, for instance to create the WORK directory 232 * ``cfg.txt`` : text list of configurations and source directories 233 * ``bld.cfg`` : FCM rules to compile 234 235 Examples 236 -------- 237 238 .. literalinclude:: ../../../makenemo 239 :language: text 240 :lines: 146-153 241 242 Running the model 243 ================= 244 245 Once ``makenemo`` has run successfully, 246 the ``nemo`` executable is available in ``./cfgs/MY_CONFIG/EXP00``. 247 For the reference configurations, the ``EXP00`` folder also contains the initial input files 248 (namelists, ``*.xml`` files for the IOs, ...). 249 If the configuration needs other input files, they have to be placed here. 250 251 .. code-block:: sh 252 253 cd 'MY_CONFIG'/EXP00 254 mpirun -n $NPROCS ./nemo # $NPROCS is the number of processes 255 # mpirun is your MPI wrapper 256 257 Viewing and changing list of active CPP keys 258 ============================================ 259 260 For a given configuration (here called ``MY_CONFIG``), 261 the list of active CPP keys can be found in :file:`./cfgs/'MYCONFIG'/cpp_MY_CONFIG.fcm` 262 263 This text file can be edited by hand or with ``makenemo`` to change the list of active CPP keys. 264 Once changed, one needs to recompile ``nemo`` in order for this change to be taken in account. 265 Note that most NEMO configurations will need to specify the following CPP keys: 266 ``key_iomput`` for IOs and ``key_mpp_mpi`` for parallelism. -
NEMO/trunk/README.rst
r11713 r11723 20 20 These physical core engines are described in 21 21 their respective `reference publications <#project-documentation>`_ that 22 must be cited for any work related to their use (see :doc:`cit ations`).22 must be cited for any work related to their use (see :doc:`cite`). 23 23 24 24 Assets and solutions … … 30 30 - Create :doc:`embedded zooms<zooms>` seamlessly thanks to 2-way nesting package AGRIF_. 31 31 - Opportunity to integrate an :doc:`external biogeochemistry model<tracers>` 32 - Versatile :doc:`data assimilation<da ta_assimilation>`33 - Generation of :doc:`diagnostics<diag nostics>` through effective XIOS_ system34 - Roll-out Earth system modeling with :doc:`coupling interface<c oupling>` based on OASIS_32 - Versatile :doc:`data assimilation<da>` 33 - Generation of :doc:`diagnostics<diags>` through effective XIOS_ system 34 - Roll-out Earth system modeling with :doc:`coupling interface<cplg>` based on OASIS_ 35 35 36 Several :doc:`built-in configurations<c onfigurations>` are provided to36 Several :doc:`built-in configurations<cfgs>` are provided to 37 37 evaluate the skills and performances of the model which 38 38 can be used as templates for setting up a new configurations (:file:`./cfgs`). 39 39 40 The user can also checkout available :doc:`idealized test cases<test _cases>` that40 The user can also checkout available :doc:`idealized test cases<tests>` that 41 41 address specific physical processes (:file:`./tests`). 42 42 -
NEMO/trunk/cfgs/AGRIF_DEMO/README.rst
r10460 r11723 20 20 =========== 21 21 22 Activating AGRIF requires to append the cpp key ``key_agrif`` at compilation time: 22 Activating AGRIF requires to append the cpp key ``key_agrif`` at compilation time: 23 23 24 24 .. code-block:: sh … … 54 54 depends on the number of ghost cells as illustrated by the (attempted) drawing below for nbghostcells=1 and 55 55 nbghostcells=3. 56 The grid refinement is 3 and nxfin is the number of child grid points in i-direction. 56 The grid refinement is 3 and nxfin is the number of child grid points in i-direction. 57 57 58 58 .. image:: _static/agrif_grid_position.jpg … … 62 62 boundary data exchange and update being only performed between root and child grids. 63 63 Use of east-west periodic or north-fold boundary conditions is not allowed in child grids either. 64 Defining for instance a circumpolar zoom in a global model is therefore not possible. 64 Defining for instance a circumpolar zoom in a global model is therefore not possible. 65 65 66 66 Preprocessing … … 92 92 rn_sponge_dyn = 2880. ! coefficient for dynamics sponge layer [m2/s] 93 93 ln_chk_bathy = .false. ! =T check the parent bathymetry 94 / 94 / 95 95 96 96 where sponge layer coefficients have to be chosen according to the child grid mesh size. 97 97 The sponge area is hard coded in NEMO and applies on the following grid points: 98 2 x refinement factor (from i=1+nbghostcells+1 to i=1+nbghostcells+sponge_area) 98 2 x refinement factor (from i=1+nbghostcells+1 to i=1+nbghostcells+sponge_area) 99 99 100 References 101 ========== 100 .. rubric:: References 102 101 103 102 .. bibliography:: zooms.bib 104 105 106 107 103 :all: 104 :style: unsrt 105 :labelprefix: A 106 :keyprefix: a- -
NEMO/trunk/cfgs/README.rst
r11708 r11723 296 296 while lateral boundary conditions for dynamical fields have 3 days time frequency. 297 297 298 References 299 ========== 300 301 .. bibliography:: configurations.bib 298 .. rubric:: References 299 300 .. bibliography:: cfgs.bib 302 301 :all: 303 302 :style: unsrt 304 303 :labelprefix: C 305 306 .. Links and substitutions -
NEMO/trunk/src/TOP/README.rst
r11713 r11723 208 208 209 209 The overall data structure (Fortran type) is based on the general one defined for NEMO core in the SBC component 210 (see details in ``SBC`` Chapter of :doc:`Reference Manual <cit ations>` on Input Data specification).210 (see details in ``SBC`` Chapter of :doc:`Reference Manual <cite>` on Input Data specification). 211 211 212 212 Input fields are prescribed within ``&namtrc_dta`` (with ``sn_trcdta`` structure), … … 230 230 Note that, the Lateral Open Boundaries conditions are applied on 231 231 the segments defined for the physical core of NEMO 232 (see ``BDY`` description in the :doc:`Reference Manual <cit ations>`).232 (see ``BDY`` description in the :doc:`Reference Manual <cite>`). 233 233 234 234 :file:`namelist_trc` … … 286 286 :file:`trcwri_my_trc.F90` 287 287 This routine performs the output of the model tracers (only those defined in ``&namtrc``) using 288 IOM module (see chapter “Output and Diagnostics” in the :doc:`Reference Manual <cit ations>`).288 IOM module (see chapter “Output and Diagnostics” in the :doc:`Reference Manual <cite>`). 289 289 It is possible to place here the output of additional variables produced by the model, 290 290 if not done elsewhere in the code, using the call to ``iom_put``. -
NEMO/trunk/tests/README.rst
r10605 r11723 13 13 14 14 .. contents:: 15 15 :local: 16 16 17 17 Procedure … … 34 34 ------------------------------ 35 35 36 There no requirement of specific input file for the test_cases presented here. The XIOS xml input files and namelist are already setup correctly. 36 There no requirement of specific input file for the test_cases presented here. The XIOS xml input files and namelist are already setup correctly. 37 37 For detailed description and Jupyter notebook, the reader is directed on 38 38 the `NEMO test cases repository <http://github.com/NEMO-ocean/NEMO-examples>`_ … … 42 42 ICE_AGRIF 43 43 ========= 44 44 45 45 This test case illustrates the advection of an ice patch across an East/West and North/South periodic channel 46 46 over a slab ocean (i.e. one ocean layer), and with an AGRIF zoom (1:3) in the center 47 The purpose of this configuration is to test the advection of the ice patch in 47 The purpose of this configuration is to test the advection of the ice patch in 48 48 and across the AGRIF boundary 49 49 One can either impose ice velocities or ice-atm. stresses and let rheology define velocities … … 54 54 VORTEX 55 55 ====== 56 56 57 57 This test case illustrates the propagation of an anticyclonic eddy over a Beta plan and a flat bottom. 58 58 It is implemented here with an online refined subdomain (1:3) out of which the vortex propagates. 59 59 It serves as a benchmark for quantitative estimates of nesting errors as in Debreu et al. (2012) :cite:`DEBREU2012`, 60 60 Penven et al. (2006) :cite:`PENVEN2006` or Spall and Holland (1991) :cite:`SPALL1991`. 61 61 62 62 The animation below (sea level anomaly in meters) illustrates with two 1:2 successively nested grids how 63 63 the vortex smoothly propagates out of the refined grids. 64 64 65 65 .. image:: _static/VORTEX_anim.gif 66 66 … … 69 69 70 70 The purpose of this test case is to evaluate the impact of various schemes and new development with the iceshelf cavities circulation and melt. 71 This configuration served as initial assesment of the ice shelf module in Losh et al. (2008) :cite:`LOSCH2008` and Mathiot et al. (2017) :cite:`MATHIOT2017`. 71 This configuration served as initial assesment of the ice shelf module in Losh et al. (2008) :cite:`LOSCH2008` and Mathiot et al. (2017) :cite:`MATHIOT2017`. 72 72 The default setup is the one described `here <http://staff.acecrc.org.au/~bkgalton/ISOMIP/test_cavities.pdf>`_. 73 73 74 74 The figure below (meridional overturning circulation) illustrates the circulation generated after 10000 days by the ice shelf melting (ice pump). 75 75 … … 82 82 by Haidvogel and Beckmann (1999) :cite:`HAIDVOGEL1999` for testing advection schemes in ocean circulation models. 83 83 It has been used by several authors including Burchard and Bolding (2002) :cite:`BURCHARD2002` and Ilicak et al. (2012) :cite:`ILICAK2012`. 84 The LOCK EXCHANGE experiment can in particular illustrate the impact of different choices of numerical schemes 84 The LOCK EXCHANGE experiment can in particular illustrate the impact of different choices of numerical schemes 85 85 and/or subgrid closures on spurious interior mixing. 86 86 … … 92 92 ======== 93 93 94 The OVERFLOW experiment illustrates the impact of different choices of numerical schemes 95 and/or subgrid closures on spurious interior mixing close to bottom topography. 96 The OVERFLOW experiment is adapted from the non-rotating overflow configuration described 94 The OVERFLOW experiment illustrates the impact of different choices of numerical schemes 95 and/or subgrid closures on spurious interior mixing close to bottom topography. 96 The OVERFLOW experiment is adapted from the non-rotating overflow configuration described 97 97 in Haidvogel and Beckmann (1999) :cite:`HAIDVOGEL1999` and further used by Ilicak et al. (2012) :cite:`ILICAK2012`. 98 98 Here we can assess the behaviour of the second-order tracer advection scheme FCT2 and fortht-order FCT4, z-coordinate and sigma coordinate (...). … … 105 105 === 106 106 107 A set of simple closed basin geometries for testing the Wetting and drying capabilities. 107 A set of simple closed basin geometries for testing the Wetting and drying capabilities. 108 108 Examples range from a closed channel with EW linear bottom slope to a parabolic EW channel with a Gaussian ridge. 109 109 110 110 Below the animation of the test case 7. This test case is a simple linear slope with a mid-depth shelf with an open boundary forced with a sinusoidally varying ssh. 111 111 This test case has been introduced to emulate a typical coastal application with a tidally forced open boundary with an adverse SSH gradient that, when released, creates a surge up the slope. … … 123 123 ICE_ADV2D 124 124 ========= 125 125 126 126 This test case illustrates the advection of an ice patch across an East/West and North/South periodic channel 127 127 over a slab ocean (i.e. one ocean layer). … … 130 130 (for now, Prather and Ultimate-Macho from 1st to 5th order), 131 131 especially the occurence of overshoots in ice thickness 132 132 133 133 134 134 ICE_ADV1D 135 135 ========= 136 136 137 137 This experiment is the classical Schar & Smolarkiewicz (1996) test case :cite:`SCHAR1996`, 138 138 which has been used in :cite:`LIPSCOMB2004`, … … 141 141 The purpose of this configuration is to test the caracteristics of advection schemes available in the sea-ice code 142 142 (for now, Prather and Ultimate-Macho from 1st to 5th order), 143 especially the constitency between concentration, thickness and volume, and the preservation of initial shapes. 143 especially the constitency between concentration, thickness and volume, and the preservation of initial shapes. 144 144 145 References 146 ========== 145 .. rubric:: References 147 146 148 .. bibliography:: test _cases.bib149 150 151 147 .. bibliography:: tests.bib 148 :all: 149 :style: unsrt 150 :labelprefix: T -
utils/build/makenemo
r11692 r11723 52 52 # - TOOLS_DIR : " " " 53 53 # - NEMO_DIR : " " " 54 # - REMOTE_CTL : URL link to a remote resource list for an external configuration 54 # - REMOTE_CTL : URL link to a remote resource list for an external configuration 55 55 # which is not part of the reference suite 56 # - LOCAL_REF : Nearest reference configuration to an external configuration 56 # - LOCAL_REF : Nearest reference configuration to an external configuration 57 57 # which is not part of the reference suite 58 58 # (used to populate work directories if remote access is not available) … … 119 119 Usage: 120 120 ------ 121 ./makenemo -[aru] CONFIG -m ARCH [-[dehjntv] ...] [{list_key,clean,clean_config}] [{add_key,del_key} ...] 122 123 Mandatory: 124 -m Computing architecture (./arch), FCM file describing the compilation settings 121 ./makenemo -[aru] CONFIG -m ARCH [-[dehjntv] ...] [{list_key,clean,clean_config}] 122 [{add_key,del_key} ...] 123 124 Mandatory 125 -m Computing architecture (./arch), FCM file describing the compilation settings 126 125 127 and one of the following option (use 'all' arg to list available items) 126 -r Reference configuration (./cfgs), proven with long-term support until the EOL of the release 127 -a Academic test case (./tests), ready to use at the release start without guarantee or support over time 128 -u Scripted remote configuration (see ./tests/rmt_cfgs.txt) 129 130 Optional: 131 -d New set of sub-components (list from ./src directory) 132 -e Path for alter patch location (default: 'MY_SRC' in configuration folder) 133 -h Print this help 134 -j Number of processes to compile (0: dry run with no build) 135 -n Name for new configuration 136 -s Path for alter source location (default: 'src' root directory) 137 -t Path for alter build location (default: 'BLD' in configuration folder) 138 -v Level of verbosity ([0-3]) 139 140 Examples: 128 129 -r Reference configuration (./cfgs), proven with long-term support 130 -a Academic test case (./tests), ready-to-use configuration with no support over time 131 -u Scripted remote configuration (see ./tests/rmt_cfgs.txt) 132 133 Optional 134 -d New set of sub-components (subfolders from ./src directory) 135 -e Path for alter patch location (default: 'MY_SRC' in configuration folder) 136 -h Print this help 137 -j Number of processes to compile (0: dry run with no build) 138 -n Name for new configuration 139 -s Path for alter source location (default: 'src' root directory) 140 -t Path for alter build location (default: 'BLD' in configuration folder) 141 -v Level of verbosity ([0-3]) 142 143 Examples 141 144 ¤ Configuration creation 142 Build : ./makenemo -[aru] ... [...]145 Build : ./makenemo -[aru] ... [...] 143 146 Copy : ./makenemo -n ... -[aru] ... [...] 144 147 ¤ Configuration management 145 List CPP keys : ./makenemo [...]list_key146 Add-Remove keys: ./makenemo [...]add_key '...' del_key '...'147 Fresh start : ./makenemo [...]clean148 Erasure : ./makenemo [...]clean_config148 List CPP keys : ./makenemo -n ... list_key 149 Add-Remove keys: ./makenemo -n ... add_key '...' del_key '...' 150 Fresh start : ./makenemo -n ... clean 151 Removal : ./makenemo -n ... clean_config 149 152 EOF 150 153 exit 0 ;; … … 258 261 else 259 262 260 ## Reuse a working cfg 263 ## Reuse a working cfg 261 264 if [[ -f ${CONFIG_DIR}/work_cfgs.txt && $( grep "${TML_CONF} " ${CONFIG_DIR}/work_cfgs.txt ) ]]; then 262 265 conf_file=work_cfgs.txt … … 362 365 363 366 ## if AGRIF we do a first preprocessing 364 if [[ ${#x_c} -eq 0 && "$AGRIFUSE" -eq 1 ]]; then 367 if [[ ${#x_c} -eq 0 && "$AGRIFUSE" -eq 1 ]]; then 365 368 fcm build --ignore-lock -j 1 ${COMPIL_DIR}/bld_preproagr.cfg ||{ cd - ; exit 1 ;} 366 369 echo ''
Note: See TracChangeset
for help on using the changeset viewer.