source: NEMO/branches/2020/dev_r12512_HPC-04_mcastril_Mixed_Precision_implementation/cfgs/SHARED @ 12531

Name Size Rev Age Author Last Change
axis_def_nemo.xml 1.8 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
domain_def_nemo.xml 12.6 KB 12276   22 months cetlod trunk : merge in some cmip6 diagnostics into the trunk before copying it …
field_def_nemo-ice.xml 56.7 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
field_def_nemo-innerttrc.xml 4.3 KB 9539   3 years cetlod dev_merge_2017 : validation of Offline configurations
field_def_nemo-oce.xml 117.0 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
field_def_nemo-pisces.xml 32.5 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
grid_def_nemo.xml 9.6 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
namelist_ice_ref 18.1 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
namelist_pisces_ref 30.8 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
namelist_ref 110.2 KB 12530   19 months smueller Explicit activation of the sea-ice component in the namelists for the …
namelist_top_ref 9.7 KB 12377   20 months acc The big one. Merging all 2019 developments from the option 1 branch back …
namelist_trc_ref 2.3 KB 9613   3 years lovato trunk : redo bugfix of CFC gas transfer velocity and add CDIAC forcing …
README.namelists 3.5 KB 9532   3 years gm dev_merge_2017: end of the renaming MLE
README.rst 4.4 KB 11747   2 years nicolasmartin Review README for diagnostics


Simple style rules for namelists

NEMO reference namelists should adhere to the following simple style rules:

1. Comments outside a namelist block start with !! in column 1
2. Each namelist block starts with 3 lines of the form:

&namblockname        !   short description of block

        with all ! and & 's starting in column 1
3. The closing / for each namelist block is in column 1
4. Comments within namelist blocks never start with !- . Use ! followed
        by space or != etc. 

These conventions make it possible to construct empty configuration namelists.
For example, a namelist_cfg template can be produced from namelist_ref with
the following grep command; e.g.:

grep -E  '^!-|^&|^/' namelist_ref > namelist_cfg.template

head namelist_cfg.template
&namrun        !   parameters of the run
&namcfg        !   parameters of the configuration                     
&namdom        !   time and space domain

If all configuration namelists are produced and maintained using this
strategy then standard, side-by-side comaparators, such as vimdiff or xxdiff,
can be used to compare and transfer lines from the reference namelist to a
configuration namelist when setting up a new configuration.

Tips and tricks

1. The following bash function is useful when checking which namelist blocks
are in active use in a configuration namelist:

  function  list_used_nl(){ grep -n -E '^&|^/' "$1" | sed -e 's/:/ /' \
    | awk ' BEGIN { x = 0 } \
      {if ( NR % 2 == 0 && $1 - x > 2 ) printf("%3d  %s\n", $1 - x , n) ; \
       else x = $1; n = $2}' \
    | sort -k 2;}

which (assuming the namelist adheres to the conventions) will list the number
of entries in each non-empty namelist block. The list is sorted on the block
name to ease comparisons. For example:

  list_used_nl ORCA2_LIM3_PISCES/EXP00/namelist_cfg

  1 &nambbc
  5 &nambbl
  30 &namberg
  10 &namcfg
  4 &namctl
  3 &namdom
  1 &namdrg
  5 &namdyn_adv
  1 &namdyn_hpg
  22 &namdyn_ldf
  1 &namdyn_spg
  5 &namdyn_vor
  3 &nameos
  1 &namhsb
  4 &namrun
  1 &namsbc
  1 &namsbc_blk
  3 &namtra_adv
  28 &namtra_ldf
  10 &namtra_ldfeiv
  25 &namzdf
  3 &namzdf_iwm

2. vimdiff can give garish colours in some terminals. Usually this is because
vim assumes, incorrectly, that the terminal only supports 8 colours. Try forcing
256 colours with:

  :set t_Co=256

to produce more pastel shades (add this to ~/.vimrc if successful).

3. Switching between vsplit panes in vim is a multi-key sequence. The tool is 
much easier to use if the sequence is mapped to a spare key. Here I use the
§ and ± key on my Mac keyboard (add to ~/.vimrc):

  map § ^Wl
  map ± ^Wh 

4. With easy switching between panes, constructing namelists in vimdiff just
requires the following commands in addition to normal editing:

  ]c    - Go to next block of the diff
  dp    - Push version of the block under cursor into the other pane
  do    - Pull version of the block under cursor from the other pane



.. todo::

.. contents::

Output of diagnostics in NEMO is usually done using XIOS.
This is an efficient way of writing diagnostics because
the time averaging, file writing and even some simple arithmetic or regridding is carried out in
parallel to the NEMO model run.
This page gives a basic introduction to using XIOS with NEMO.
Much more information is available from the :xios:`XIOS homepage<>` above and from the NEMO manual.

Use of XIOS for diagnostics is activated using the pre-compiler key ``key_iomput``.

Extracting and installing XIOS

1. Install the NetCDF4 library.
   If you want to use single file output you will need to compile the HDF & NetCDF libraries to
   allow parallel IO.
2. Download the version of XIOS that you wish to use.
   The recommended version is now XIOS 2.5:

   .. code-block:: console

      $ svn co

and follow the instructions in :xios:`XIOS documentation <wiki/documentation>` to compile it.
If you find problems at this stage, support can be found by subscribing to
the :xios:`XIOS mailing list <../mailman/listinfo.cgi/xios-users>` and sending a mail message to it.

XIOS Configuration files

XIOS is controlled using XML input files that should be copied to
your model run directory before running the model.
Examples of these files can be found in the reference configurations (:file:`./cfgs`).
The XIOS executable expects to find a file called :file:`iodef.xml` in the model run directory.
In NEMO we have made the decision to use include statements in the :file:`iodef.xml` file to include:

- :file:`field_def_nemo-oce.xml` (for physics),
- :file:`field_def_nemo-ice.xml` (for ice),
- :file:`field_def_nemo-pisces.xml` (for biogeochemistry) and
- :file:`domain_def.xml` from the :file:`./cfgs/SHARED` directory.

Most users will not need to modify :file:`domain_def.xml` or :file:`field_def_nemo-???.xml` unless
they want to add new diagnostics to the NEMO code.
The definition of the output files is organized into separate :file:`file_definition.xml` files which
are included in the :file:`iodef.xml` file.


Detached Mode

In detached mode the XIOS executable is executed on separate cores from the NEMO model.
This is the recommended method for using XIOS for realistic model runs.
To use this mode set ``using_server`` to ``true`` at the bottom of the :file:`iodef.xml` file:

.. code-block:: xml

   <variable id="using_server" type="boolean">true</variable>

Make sure there is a copy (or link to) your XIOS executable in the working directory and
in your job submission script allocate processors to XIOS.

Attached Mode

In attached mode XIOS runs on each of the cores used by NEMO.
This method is less efficient than the detached mode but can be more convenient for testing or
with small configurations.
To activate this mode simply set ``using_server`` to false in the :file:`iodef.xml` file

.. code-block:: xml

   <variable id="using_server" type="boolean">false</variable>

and don't allocate any cores to XIOS.

.. note::

   Due to the different domain decompositions between XIOS and NEMO,
   if the total number of cores is larger than the number of grid points in the ``j`` direction then
   the model run will fail.

Adding new diagnostics

If you want to add a NEMO diagnostic to the NEMO code you will need to do the following:

1. Add any necessary code to calculate you new diagnostic in NEMO
2. Send the field to XIOS using ``CALL iom_put( 'field_id', variable )`` where
   ``field_id`` is a unique id for your new diagnostics and
   variable is the fortran variable containing the data.
   This should be called at every model timestep regardless of how often you want to output the field.
   No time averaging should be done in the model code.
3. If it is computationally expensive to calculate your new diagnostic
   you should also use "iom_use" to determine if it is requested in the current model run.
   For example,

   .. code-block:: fortran

      IF iom_use('field_id') THEN
         !Some expensive computation
    iom_put('field_id', variable)

4. Add a variable definition to the :file:`field_def_nemo-???.xml` file.
5. Add the variable to the :file:`iodef.xml` or :file:`file_definition.xml` file.
Note: See TracBrowser for help on using the repository browser.