NEMO@POLR

De POLR
Sauter à la navigation Sauter à la recherche

Introduction

Ce document vise à documenter l’utilisation de NEMO sur la grappe de calcul Mingan à l’UQAR. Plusieurs des informations proviennent de site officiel de NEMO.

NEMO au POLR

À l'ISMER, NEMO a été choisi comme successeur de MOR. Cette section décrit brièvement certaines informations utiles pour utiliser NEMO mais également l'environnement dans lequel il est utilisé sur la grappe de calculs de l'UQAR.

Afin de conserver l'historique lié à un projet, nous avons conçu une enveloppe qui, à l'aide de Git, conserve l'historique des modifications du code et celui de ces composantes. Pour ce faire, nous avons opté pour l'utilisation de sous-modules. Nous avons nommé cette enveloppe "Coffre". Dans sa forme la plus simple, le coffre est un dépôt Git contenant des sous-modules et une structure pour stocker les configurations des simulateurs utilisés. L'idée est de s'assurer de pouvoir reproduire des simulations antérieures, que ce soit pour faire des vérifications ou bien reprendre un projet là où il avait été laissé.

Dans cet exemple, la structure du coffre sera celle liée aux spécificités du simulateur NEMO, mais chaque projet aboutira avec un coffre différent. Dans le cadre de l'utilisation avec NEMO, le premier sous-module est lié avec le code de NEMO. Ce sous-module pointe vers une révision du projet NEMO sur le GitLasso. Ce projet NEMO contient lui-même un sous-module le liant à un projet CICE sur le GitLasso également. CICE est le modèle de glace que nous avons choisi dans cet exemple. Les configurations de NEMO sont généralement incluses dans le répertoire NEMOCGM/CONFIG. Dans notre structure, ce répertoire point vers ../ISMER_NEMO_CONFIG. Ce répertoire est un élément à part entière du coffre, il contient les configurations du NEMO (ex. EXP00) et les modifications du code (MY_SRC). Nous avons ajouté un autre sous-module nommé outils_ISMER qui contient le code nécessaire pour préparer les intrants et analyser les sorties du simulateur. Donc en sauvegardant le coffre à l'aide de Git, nous conservons également toutes les informations nécessaires pour reproduire l'expérience.

Exemple:

Coffre (module Git) 

|- outils_ISMER (sous-module Git)
|- nemo 
     |-NEMOGCM (sous-module Git)
     |     |-CONFIG (lien symbolique vers ../ISMER_NEMO_CONFIG)
     |     |-NEMO
     |     |   |-CICE_SRC (sous-module Git)
     |
     |-ISMER_NEMO_CONFIG
               |- GSL5KM_CICE4
                       |- MY_SRC (code de NEMOGCM modifié)
                       |- EXP00  (expérience de NEMO)

Notions utiles pour l'utilisation de NEMO et des ses résultats

Variables et structure

Quelles sont les variables pronostiques: Champs de vitesses 3D, hauteur de la surface d'eau (non linéaire), température conservatrice, salinité absolue

Numerical indexing: An increasing horizontal index, centre for t-point, eastward u-point and northward v-point have the same index. In the vertical, k-axis is reoriented downward. The surface level is at k=1. For an increasing vertical index, a w-point and the t-point just below (centre of the mesh) have the same k index. The last w-level (k=jpk) corresponds to the ocean floor and the last t-level is INSIDE the bathymetry.

Code

Modules: Based on physics, three-letter rule, such as: 

 traldf.F90 for TRAcers equation, computing Lateral DiFusion.

Compilation du code

Que sont les clés de compilation (CPP): Ces clés servent à faire des sélections (ajout/suppression) dans le code lors de la compilation et ainsi améliorer le mémoire utilisé lors de l'exécution de NEMO. Une liste des clés est en élaboration sur ce lien Clés CPP de NEMO.

Une autre page avec plusieurs des clé de compilation. lien

Exécution du programme

Namelist: List of input variables. One namelist file for each component of NEMO. Variables listed as : 

 ln_xxx for logic (boolean) ; 
 rn_xxx for a specific value (number); 
 nn_xxx for a choice of formulation ; 
 cn_xxx for a containing directory and files? ; 
 bn_xxx for boundary files

Two namlists exist: namelist_cfg and namelist_ref. The namelise_ref is read first and then namelist_cfg. So any duplicate value in namelist_cfg will supersede the value in namelise_ref.

Domain (DOM): Total size set in the namelist namcfg with jpiglo, jpjglo, jpkdta. Sub-domain may be created with jpidta and jpjdta (zoom). Jpi and jpj refer to MPI decomposition (if key_mpp_mpi is defined).

Lateral Conditions: Model domain lateral conditions are defined in different namelists for “at the coast” (namlbc) and “open” boundaries (namobc).

At the coast, the lateral conditions depend on a mask for each grid point where the fluxes are evaluated (ex: no flux through solid boundaries). The tangential velocity is managed by rn_shlat to apply a specific mask along the coastline on the f-grid.

The Open boundary conditions (OBC) may be managed as closed or cyclic / asymetric (jperio in namcfg). For regional configurations, BDY module allows alternative implementation of OBC through several namelists : nambdy (water, ice tracers), nambdy_dta (external data), nambdy_tide (tidal forcing at OBC). nb_bdy defines the number of boundary sets. Each set may be defined as a set of straight line (ln_coords_file=.false. and nambdy_index is added) or read from file (ln_coords_file=.true. and cn_coords_file=coordinates.bdy.nc). One could use the initial condition as OBC (nn_tra_dta=0) or use data (nn_tra_dta=1). To use data, add the nambdy_dta namelist. If more than one OBC sets have been defined, one nambdy_dta namelist is required for each boundary set.

At the boundary, a flow relaxation scheme (FRS) helps prevent spurious reflection of outgoing signals. It is set as cn_dyn2d = ‘frs’ or ‘flather’ in the nambdy namelist. The width of the FRS zone is specified by nn_rimwidth (usually between 8-10). The boundaries may be defined with a mask (cn_mask_file) to apply irregular OBC (not straight lines). To force the total volume to be constant, set ln_vol = .true. and select nn_volctl = 1 to ensure that the integrated volume flow through the boundary is zero (a correction is applied to 
the normal velocities around the boundary at each timestep) and nn_volctl = 2 to include the change due to the freshwater flux. The volume correction applies to all boundaries at once.

Tides: Defined in nam_tide with the cpp key_tide. filtide defines the repertorie/file name root of tidal forcings files. In the repertory, 3 files (grid T, U, V) for each tide constituent (Q1, S1, M2, etc). All tidal components must be set in namelist_cfg (not in namelist_ref).

Surface boundary condition (SBC) : The ocean needs 6 fields as SBC : 2 components of the surface stress - tau_u, tau_v; solar and non solar heat fluxes – Qns,Qsr ; surface freshwater budget – emp ; surface salt flux due to melting/freezing of seawater – sfx ; plus an optional 7th field : the atmospheric pressure - pa. The namsbc namelist controls the five different ways to provide those fields : 

 1-analytical formulation : ln_ana = .true. -> &namsbc_ana
 2-flux formulation : ln_flx = .true. -> &namsbc_flx
 3-bulk formulae formulation, 3 options : ln_blk_xxx = .true. -> &namsbc_clio, &namsbc_core, &namsbc_mfs
 4-coupled formulation ln_cpl = .true. (requires key_oasis3)
 5-mixed forced/coupled formulation ln_mixcpl = .true. (requires key_oasis3)

Sortie de NEMO

Outputs: Standard model output (IOM) allows specifying aspects of diagnostic without code changes or recompilation (frequencies, contents, split files et a chosen frequency, extract horizontal or vertical subdomain, perform temporal operation as average, accumulate, min, max, instantaneous). Iomput also enhances performance when running in parallel.

Your iodef.xml file contains options to manage your results. To gather your several files (from MPI run) in one single file, use the option “one_file” as: 

 <file_definition type="one_file" name "@expname@_@freq@_@startdate@_@enddate@" sync_freq "1d" min_digits="4">

If the netcdf library doesn’t allow the ‘one_file’ option, you may Rebuilt your results (See REBUILD_NEMO tools in the next section)


Certains programmes/utilitaires doivent être installé avant d’utiliser NEMO.

Compilation FORTRAN avec Ifort

Afin de pouvoir compiler avec Parrallel Studio, des variables d’environnement doivent être définies.

  • Elles peuvent être définies à l'aide des lignes suivantes dans votre ~/.bash_profile :
    • export INTEL_LICENCE_FILE=/share/apps/intel/licenses/lincense.lic
    • source /share/apps/intel/parallel_studio_xe_2015/bin/psxevars.sh
  • Également en utilisant les modules intel/compilateurs et intel/openmpi
    • module load intel/compilateurs intel/openmpi

Installer NEMO avec FCM (depuis nemo_V3_3)

NEMO utilise un outil de gestion de code basé sur SVN, FCM (Flexible Configuration Manager, developped at UKMO ©Crown Copyright 2005-10). Pour l’utiliser, il faut utiliser le module fcm à l'aide de la commande: module load fcm

Obtenir le code de NEMO

Vous avez plusieurs choix, en voici deux. Vous pouvez lancer la commande SVN suivante pour extraire le code de NEMO:

Pour ce faire, vous devez avoir un compte pour nemo-ocean.eu. Si vous n’en avez pas, vous pouvez en faire la demande à l’adresse suivante : http://www.nemo-ocean.eu/user/login Vous avez maintenant le code de NEMO v.3.6 STABLE.

Vous pouvez également l'obtenir la version CONCEPT en demandant à Simon Senneville. Cette version contient les fichiers de configuration spécifiques pour l'utilisation de NEMO sur la grappe de calcul Mingan.

Obtenir le code et utiliser XIOS 1.0

XIOS gère les diagnostiques de sorties, les opérations temporelles/spatiales de post-traitement (parallèlement à NEMO) de façon flexible et performante (Calculs et écritures simultanées par appels asynchrones).

Pour obtenir le code et installer XIOS 1.0, vous devez suivre les étapes à l’adresse suivante : http://www.nemo-ocean.eu/Using-NEMO/User-Guides/Basics/XIOS-IO-server-installation-and-use Une version du code est déjà installée sur Mingan. XIOS est installé dans /share/apps/xios/1.0/bin/xios_server.exe.

Compiler et créer un NEMO exécutable

Le script principal pour compiler et créer NEMO se nomme makenemo et est situé dans le répertoire CONFIG. Voici un exemple avec la configuration GYRE. GYRE à l’avantage que les champs initiaux et les forçages sont analytiques, il ne nécessite donc aucun fichier d’intrant.

  • cd NEMOGCM/CONFIG;
  • ./makenemo –m mpiifort_linux –r GYRE -n MY_GYRE

Cependant, vous devez avoir le fichier arch-mpiifort_linux à votre répertoire NEMOGCM/ARCH/. Dans le cas contraire, vous aurez un message d’erreur indiquant : Compiler not existing. Ce fichier est disponible dans le version CONCEPT ou sur : /home/sennevil/projetcs/NEMOGCM/ARCH/arch-mpiifort_linux.fcm Vous avez alors un répertoire nommé NEMOGCM/CONFIG/MY_GYRE/. Ce répertoire vous permet de lancer une expérience basée sur GYRE, une configuration de base de NEMO. Il ne reste qu’à créer votre lanceur pour qsub. Un exemple de fichier existe sur Mingan dans : /home/sennevil/projects/NEMOGCM/MY_GYRE/EXP00/lanceur.pbs.

Créer un nouvelle CONFIG dans NEMO

Des informations sont également disponibles à l'adresse suivante: nemo/wiki/Users/SetupNewConfiguration

Par exemple, créons une CONFIG pour le domaine du golfe du Saint-Laurent GSL5km basé sur le configuration de MoGSL. voici les étapes nécessaires:

  • 1.Créer un répertoire pour la nouvelle configuration
-cd NEMOGCM/CONFIG
-mkdir GSL5KM
  • 2.Créer un fichier permettant à FCM de faire la compilation et la construction de l’exécutable.

Ce fichier doit contenir toutes les informations sur les clefs de précompilation pour NEMO. Dans la version du CMC, ces clefs se retrouvent dans BB_make.ldef. La définition de toutes les clefs se retrouve à l’adresse suivante : http://www.nemo-ocean.eu/Using-NEMO/User-Guides/Basics/cpp-keys-v3_4

  • 3.Ajouter les fichiers de code source relatif à la nouvelle configuration dans CONFIG/GSL5KM/MY_SRC/.
  • 4.Déterminer les paramètres de la nouvelle configuration.

Ces paramètres sont déterminés dans les fichiers CONFIG/GSL5KM/EXP00/namelist_cfg et CONFIG/GSL5KM/EXP00/namelist_ref.

  • 5.Ajouter la nouvelle configuration à cfg.txt

Le fichier se retrouve dans CONFIG/cfg.txt

  • 6.Compilation

Pour générer la nouvelle configuration MY_GSL5KM à partir de GSL5KM :

-./makenemo –r GSL5KM –n MY_GSL5KM

Pour compiler la configuration MY_GSL5KM par la suite :

-./makenemo –n MY_GSL5KM –m mpiifort_linux

L’option –m “compiler” choisi les options dans le fichier ARCH/arch_‘’compiler”.fcm

  • 7.Génération de la bathymétrie
-a.Coordinates.nc
-b.Bathy_meter.nc
  • 8.Génération de la condition initiale : salinité et température
  • 9.Génération des conditions frontières : salinité, température et niveau d’eau
  • 10.Génération des fichiers de rivières
  • 11.Changer le fichier namelists pour refléter les changements dans les forçages.

Utilisation des outils de NEMO

"maketools" est un script utile pour compiler les outils.

BDY_TOOLS

Description tirée de bdy_reorder.f90.

"A routine to reorder old BDY data files to make them compatible with NEMO 3.4. ... The routine is mainly for re-ordering BDY data files, but can also be used to re-order BDY coordinate files if ln_coordinates is set to .true. Author: Dave Storkey Aug 2011"

COMPILE

DMP_TOOLS

Information provenant du README.

"DMP_TOOLS should be used to create a netcdf file called resto.nc containing restoration coefficients for use with the tra_dmp module in NEMO. Further instructions for it's use are available in the NEMO users guide."

GRIDEN

Informations provenant de Nesting tools: The mesh generations by Nemo System Team, Brice Lemaire, July 9, 2010.

"The objective is to have a toolbox allowing the creation of regional configurations from curvilinear grid. The first part will explain the method in that general case. With a series of procedures Fortran, we want to be able to make zooms on a domain (increasing the resolution) or a simple extraction of a sub-domain. The domain may be regional or global and the format of input and output files will be NetCDF format."

MPP_PREP

C'est un utilitaire pour optimiser le nombre de processeur utilisé. À partir de la grille, "mpp_optimiz_zoom_nc.exe" produit un fichier "processor.layout". Ce fichier vous indique les gains de chaque configuration.

Pour compiler:

  • Se placer dans le répertoire TOOLS
  • Compiler MPP_PREP à l'aide de maketools
  ex: ./maketools -m mpiifort_linux -n MPP_PREP

Pour l'utiliser:

  • Se placer dans le répertoire MPP_PREP modifier le namelist et executer "mpp_optimiz_zoom_nc.exe"


Informations provenant de Nesting tools: How to set up an MPP configuration with NEMO OPA9 by J.M. Molines, May 26, 2005.

"This document quickly describes a set of tools that were devel- opped to facilitate the setting up of MPP configuration. It is supposed that all the programs described here are installed and compiled. "

NESTING

Informations provenant de Nesting tools: NEMO/AGRIF Nesting tools: User's Guide, Jan 30, 2006 (minor update Dec 6, 2010).

"This guide presents a series of Fortran 95 procedures that could be useful for the pre-processing of OPA/NEMO 1 ocean model when running an embbeded model."

OBSTOOLS

Information provenant de: www.nemo-ocean.eu

"A series of Fortran utilities is provided with NEMO called OBSTOOLS. This are helpful in handling observation files and the feedback file output from the NEMO observation operator. "

REBUILD

REBUILD_NEMO

Informations tirées du script rebuild_nemo.

"Script to run the NEMO rebuild tool to rebuild NEMO diagnostic or restart files.

The scripts creates the nam_rebuild namelist based upon the command line options you give it (see usage below)

Ed Blockley, September 2011"

Pour compiler:

  • Se placer dans le répertoire TOOLS
  • Compiler REBUILD_NEMO à l'aide de maketools
  ex: ./maketools -m mpiifort_linux -n REBUILD_NEMO

Pour l'utiliser:

  • Se placer dans le répertoire où est le fichier
  • Lancer rebuild_nemo, l'option -t 1 est nécessaire avec notre version de NetCDF
 ex: ../../../TOOLS/REBUILD_NEMO/rebuild_nemo -t 1 toto_T 8

Dans cet exemple, les fichiers toto_T_0000.nc à toto_T_0007.nc seront assemblés dans toto_T.nc

SECTIONS_DIADCT

Semble être destiné pour faire des diagnostics pour des sections.

SIREN

Informations provenant de : nemo/wiki/Users/SetupNewConfiguration

"Use the SIREN tools to subset an existing model ... to create all the input files you need to run a NEMO regional configuration."

http://forge.ipsl.jussieu.fr/nemo/doxygen/index.html

WEIGTHS

Informations provenant de : nocsSCRIP v1.1 03/11/2010, Author: NOCS NEMO Team

"This directory contains software for generating and manipulating interpolation weights for use with the Interpolation On the Fly (IOF) option in NEMO v3 onwards."

SETTE

Outils de validation. Information utiles dans : NEMO validation tools Documentation, Release 1.0.1, C. Levy, 20120330.

Utiliser et gérer NEMO

Afin de conserver une trace des développements de NEMO à l'ISMER et de tous les outils nécessaires pour reproduire la simulation, nous avons opté pour un système de sous-module dans GIT. Cette page du WIKI POLR documente l'utilisation de l'outil COFFRE_ET_NEMO. L'idée générale est de contenir dans un coffre, géré par GIT, toutes les informations nécessaires à reproduire la simulation (code NEMO, code CICE, code MATLAB pour produire les intrants, etc.).

Un mécanisme de restart automatisé a été mis en place au POLR. Pour savoir comment l'utiliser, veuillez vous référer à la documentation de nemo_restart.

Récupérée de « https://srwebpolr01.uqar.ca/polr/index.php?title=NEMO@POLR&oldid=2151 »