NEMO 3.4

NEMO 3.4 guide

Getting the code

(local note)
. s.ssmuse.dot nemo-3.4
clone_nemo
clones the nemo 3.4 image from our git repository (st/skynet/beluga/participating workstations/guillimin)
the s.f90 "nemo architecture" can be used to compile with our tools

• First of all, registration is required at NEMO's web site: http://www.nemo-ocean.eu
• Download NEMO by entering the following command from the directory where the model will be copied (where "mylogin" is the username selected when registering at NEMO):

  svn --username "mylogin" co -r 3819 http://forge.ipsl.jussieu.fr/nemo/svn/branches/2012/dev_v3_4_STABLE_2012

The model will be located in dev_v3_4_STABLE_2012/NEMOGCM.

Compilation

Compilation of the model can be done by calling the script makenemo in NEMOGCM/CONFIG. Help for this script can be found by entering makenemo -h.

Common options:

• -m COMP: use compiling options referred by COMP. Must be specified the first time the script is called! After that, if not specified, defaults to the last options used. The compiling options available can be found in NEMOGCM/ARCH; the ones that will be used are the ones specified in arch-COMP.fcm.

• -n CONF: specifies which configuration to compile; CONF refers to one of the subdirectories in NEMOGCM/CONFIG. If not specified, defaults to the last configuration used. If used with -r, CONF is the name of the new configuration created.

• -r REFCONF: reference configuration; allows creating a new configuration based on an existing one (specified by REFCONF). Must be used with -n.

• -j#: determines how many parallel processes are used for compilation (-j0: no compilation).

• add_key LIST, del_key LIST: adds (or deletes) one or more C pre-processor keys to be used in the compilation, LIST being a list of keys enclosed between double quotes. The list of CPP keys used for a given configuration can be found in the file cpp_CONF.fcm located in the config's directory; the list of all CPP keys available can be found here.

• clean: cleans a configuration.

Once a configuration has been compiled, the three following subdirectories should appear in the configuration directory: EXP00, MY_SRC, WORK.

Example:

 ./makenemo -n GLK -j20 -m s.f90 add_key "key_trabbl key_lim2 key_ldfslp key_traldf_c2d  key_dynldf_c3d key_zdftke key_zdfddm  key_glk \
                                                                    key_trddyn key_trdtra key_dynspg_flt key_mpp_mpi key_mpp_rep"

Modifying the code

There are two ways to modify the code:

• The subdirectory MY_SRC can be used to store modified sources. These files are used only when compiling the given configuration, and take precedence over the original code, so copying an original source file from the WORK directory to the MY_SRC directory allows changing the program without modifying the original code.

• The subdirectory WORK contains links to all the source files used to build the program. Opening and changing any of these files will modify the original source code (unless the link points to the MY_SRC subdirectory), and take effect on all configurations.

Setting up a simulation

A guide covering the basic aspects of the set-up (namelist, input files) can be found here.

Grid definition

Parameters for the horizontal grid are hard-coded in the model. They are typically stored in header files named par_${gridconf}.h90, which are then used in par_oce.F90, depending on the CPP key that is defined. In order to define a new grid, the best way is to copy one of the header files to use as a template, and then add the new header file in par_oce, with its own CPP key. The important parameters are:

• jpidta: number of points in the first dimension.
• jpjdta: number of points in the second dimension.
• jphgr_msh: type of grid. Setting this to 0 will make NEMO use the grid defined in coordinates.nc; setting it to any other value (1 to 5) makes it define an analytical grid.

The vertical grid depends mostly on the bathymetry file used.

Parameters for the vertical grid are mostly defined in the namelist. The only exception is the maximal number of levels (jpkdta), which is defined in the par_oce header files.

Required input

All files described below must be in NetCDF format.

• coordinates.nc: contains the definition (longitude, latitude, scale factors in each direction) of the grid points in the horizontal grid.

• bathy_meter.nc: contains the bathymetry in meters.

• temperature and salinity: Names and location must be defined in the &namtsd namelist.

Running the model

The subdirectory EXP00 contains a link to the NEMO executable (opa) as well as a namelist containing various parameters for the run. To start a simulation, copy all necessary input files in EXP00, and then execute opa from that directory.

To run the model with MPI, simply make sure that the program was compiled with key_mpp_mpi enabled. When the model is executed, it will automatically subdivide the horizontal domain based on the number of processes available.

Outputs

Output files are written in EXP00. The outputs for the ocean dynamics are written in four NetCDF files, with names under the following format:

${cn_exp}_${timestep}_${startdate}_${enddate}_grid_[TUVW].nc 

Other files might be produced, for instance if sea ice was modelled.

If the model was running using MPI, each output file will be split in several parts, one for each processor. A postprocessing tool (rebuild_nemo) to combine all subparts into one single file is provided with NEMO, but it must be compiled.

• To compile rebuild_nemo, go in NEMOGCM/TOOLS and execute the following command (where COMP is the compile argument used with the makenemo script):

  maketools -m COMP -n REBUILD_NEMO

• The program rebuild_nemo uses two arguments: the base name of the files to merge (corresponds to the names of the files, with the process number and the .nc extension removed), and the number of files.

• If the files to rebuild are very large, rebuild_nemo might not work properly. To avoid this problem, the option -c# can be used to process the files by chunks.

Restarting a simulation

Besides the outputs, NEMO will produce a number of restart files (name format: ${cn_exp}_${timestep}_${cn_ocerst_out}_${procnb}.nc), which can be used to restart a run. This can be done by making the following changes on the namelist:

ln_rstart: must be set to true.

nn_it000, nn_itend: nn_it000 should be set to the first time step of the restarted run, namely the time step of the restart file + 1. nn_itend should be set accordingly.

nn_rstctl: this should be set to 2. That way, the initial date will be taken from the restart file, saving the trouble of setting nn_date0 to a consistent value.

cn_ocerst_in: normally, this should correspond to the restart name suffix (cn_ocerst_out), but this won't work as expected. Instead, this parameter must be set to the name of the restart file (without the process number and the file extension).

Note: rebuilding the restart file is not necessary, unless the restart runs on a different number of processors!