_______________________________________________________________________

Cómo ejecutar WRF V3.9 en Yaku

Febrero 2018
Autor:​ Dardo Ariel Viñas Viscardi
Versión:​ 1A

1 Introducción
El presente informe ha sido realizado con el propósito de dejar documentado el
proceso de ejecución del modelo WRF, en su versión 3.9 con datos provenientes de GFS.
El mismo parte desde la finalización de la guía de instalación elaborada por este mismo
equipo de como compilar y configurar WRF, tanto en ICC como GCC.

El proceso consta de la siguientes etapas:

1 - Pre-procesamiento
2 - Procesamiento
3 - Post-procesado

Como última instancia, además, se agrega un capítulo explicando cuales son los pasos
necesarios para ejecutar el modelo en el cluster YAKU del LH-CETA. A continuación se
detalla cada etapa.

2 Pre-procesamiento
Para comenzar la ejecución del modelo es necesario contar, por un lado, con los
archivos ​GFS de la fecha que se desea modelar. Estos archivos tienen la extensión ​“.grib2”
y pueden ser descargados desde la web del ​NOAA ​(​http://nomads.ncep.noaa.gov​). Una vez
descargados los ​GFS ​que se necesitan para una determinada fecha, es necesario
configurar adecuadamente el namelist para ejecutar el modelo sobre esa determinada
fecha.

2.1 Armado del namelist

El ​namelist ​contiene toda la información de la ejecución de ​WPS que va a realizarse.
Las diferentes variables se aplican a diferentes aplicaciones, pero a continuación se detallan
alguna de ellas:

&share (opciones de control sobre la operaciones temporales, opción de control sobre el

núcleo de cálculo, anidados y datos estáticos)
wrf_core = 'ARW', (Solver)
max_dom = 1, (Cantidad de dominios – para hacer uso de la opción anidado) (1 un solo
dominio sin anidados)
start_date = '2017-10-24_00:00:00','2017-11-14_06:00:00'​ (fecha de inicio)
 _______________________________________________________________________
end_date = '2017-10-24_03:00:00','2017-11-15_15:00:00' ​(fecha de finalización)
interval_seconds = 10800 ​(Intervalo de tiempo entre datos meteorológicos de entrada
en segundos)
io_form_geogrid = 2,​ (Para trabajar en formatos netcdf)

&geogrid ​(definición del dominio, anidados, proyecciones y datos estáticos)

parent_id = 1, 1, ​(definición de dominios “padres”)
parent_grid_ratio = 1, 3, ​(Definición de relación de tamaños)
i_parent_start = 1, 31, ​(Definición de posición del anidado)
j_parent_start = 1, 17, ​(Definición de posición del anidado)
e_we = 270, 112, ​(Definición de dimensiones del dominio)
e_sn = 270, 97,​(Definición de posición del dominio)
geog_data_res = 'default','default', ​(Resolución de datos estáticos)
dx = 4000, ​(Distancia entre puntos de grilla)
Dy = 4000, ​(Distancia entre puntos de grilla)
map_proj = 'lambert', ​(Proyección del dominio de simulación, the Lambert conformal
projection is well suited for mid-latitude domains)
ref_lat = -32.5, ​(lat, lon del punto central del dominio)
ref_lon = -62.7,​(lat, lon del punto central del dominio)
truelat1 = -60.0​,(lat, lon referencias para la proyección Lambert)
truelat2 = -30.0,​(lat, lon referencias para la proyección Lambert)
stand_lon = -62.7,​(lon de ref paralela a ref_lon)
geog_data_path = '/home/localadmin/Build_WRF/WPS_GEOG/' ​(path
datos estáticos)

2.2 Ejecución de WPS

El pre procesamiento consta de 3 etapas.

1 - Geogrid
2 - Ungrib
3 - Metgrid

2.2.1 Geogrid.exe
El objetivo de GEOGRID es definir el (los) dominio (s) de simulación e interpolar
varios conjuntos de datos terrestres a las grillas del modelo.

Los dominios de simulación se definen utilizando la información especificada por el

usuario en las secciones "share" y "geogrid" del namelist de WPS.

Por defecto, además de calcular latitud y longitud para cada punto de la grilla,
Geogrid interpolará las categorías de suelo, categoría de uso del suelo, altura del terreno,
temperatura media anual del suelo, fracción de vegetación mensual, albedo mensual,
albedo máximo de nieve y categoría de pendiente para las mallas del modelo.
 _______________________________________________________________________
Este paso del software WPS debe ser ejecutado 1 vez por cada conjunto de datos
geográficos estadísticos utilizados. Los mismos son descargados a través del link provisto
en la guía anterior. Una vez descargados, se descomprime el archivo y se debe indicar en el
namelist.wps donde están ubicados estos datos geográficos:

Línea a editar en el namelist.wps

geog_data_path = '/ubicacion/de/los/datos/WPS_GEOG'

Y para ejecutar el programa, se ejecutan las siguientes líneas:

./geogrid.exe

Si se utiliza una arquitectura distribuida (MPI), se debe ejecutar con el siguiente comando:

mpirun -n N ./geogrid.exe

Siendo N el número de procesos MPI a crear.

2.2.2 Ungrib.exe
El objetivo de UNGRIB es descomprimir los datos meteorológicos GRIB (GRIB1 y
GRIB2) y empaquetarlos en un formato de archivo intermedio.

El desempaquetado de los datos se controla a través de las secciones "share" y

"ungrib" de la lista de nombres de WPS.

UNGRIB
- NO depende de ningún dominio de modelo WRF.
- NO es dependiente de GEOGRID.
- NO reduce los datos de acuerdo con las especificaciones de su modelo de dominio.
Simplemente desempaqueta los campos requeridos y los escribe en un formato que el
programa METGRID puede leer.
- utiliza Vtables (ver ejemplos de tablas en el directorio WPS / ungrib / Variable_Tables /)
para especificar qué campos desempaquetar de los archivos GRIB. Los Vtables enumeran
los campos y sus códigos GRIB que se deben desempaquetar de los archivos GRIB.

Este paso del WPS debe ser ejecutado cada vez que modelamos una nueva fecha.
Para poder ejecutarlo se debe ingresar al directorio de instalación de WPS y ejecutar las
siguiente línea de bash:

./ungrib.exe

Si se utiliza una arquitectura distribuida (MPI), se debe ejecutar con el siguiente comando:

mpirun -n N ./ungrib.exe
 _______________________________________________________________________
Siendo N el número de procesos MPI a crear.

2.2.3 Metgrid.exe
El objetivo de METGRID es interpolar horizontalmente los datos meteorológicos en el
dominio de su modelo.

La salida de metgrid.exe se usa como entrada para WRF. y es entonces el último paso del
pre-procesamiento del modelo.

Los dominios de simulación se definen utilizando la información especificada por el usuario

en las secciones "share" y "metgrid" del namelist del WPS.

Para ejecutar metgrid, se debe ejecutar:

./metgrid.exe

Si se utiliza una arquitectura distribuida (MPI), se debe ejecutar con el siguiente comando:

mpirun -n N ./metgrid.exe

Siendo N el número de procesos MPI a crear.

3 Procesamiento
Una vez finalizada la ejecución de metgrid, a la salida, se generan unos archivos con el
nombre de met_em_d<número de dominio>.<fecha>. Estos archivos deben ser copiados a
la carpeta “em_real” del directorio de instalación de WRF. El mismo se encuentra en

/directorio/de/instalación/WRFV3/test/em_real

La ejecución del modelo cuenta de 2 partes. Primero se ejecuta el programa “real.exe” y

luego “wrf.exe”. Pero antes de comenzar con la ejecución, se debe tener elaborado el
namelist de la manera adecuada.

3.1 Armado del namelist de WRF

Antes de poder ejecutar el modelo es necesario editar el archivo namelist.input con la
información del día que se quiere modelar, además de como debe hacerse ese pronóstico.

El namelist se divide en secciones:

 _______________________________________________________________________
● time_control (opciones de control sobre las operaciones temporales)

● domains (opciones de control sobre lo relacionado al dominio o dominios analizados,

tales como definición, dimensión, anidados)

● physics (opciones de parametrizaciones y representaciones)

● fdda (opciones para la asimilación de datos)

● dynamics (opciones de difusión, advección y amortiguación)

● bdy_control (opciones de control sobre las condiciones de contorno)

● grib2 (control de salida de GRIB2)

3.1.1 time_control
 _______________________________________________________________________

3.1.2 domains

3.1.3 physics

3.2 Real.exe
Habiendo finalizado la edición del namelist.input se puede proceder a la etapa del
procesamiento.
 _______________________________________________________________________
El primer paso es el programa “real.exe”. Este programa interpola verticalmente los archivos
met_em* (generados por metgrid.exe), crea archivos de límite y de condición inicial, y
realiza algunas comprobaciones de coherencia.

Para poder ejecutar el programa, se ejecutan las siguientes líneas:

./real.exe

Si se utiliza una arquitectura distribuida (MPI), se debe ejecutar con el siguiente comando:

mpirun -n N ./real.exe

Siendo N el número de procesos MPI a crear.

Al finalizar, “real.exe” habrá creado 2 archivos que son necesarios para poder ejecutar el
modelo WRF (wrf.exe).

Estos archivos son wrfbdy_d<número de dominio> y wrfinput_d<número de dominio>

3.3 Wrf.exe
Este es el programa que genera el pronóstico del modelo.

Para poder ejecutarlo, se ejecutan las siguientes líneas:

./wrf.exe

Si se utiliza una arquitectura distribuida (MPI), se debe ejecutar con el siguiente comando:

mpirun -n N ./wrf.exe

Siendo N el número de procesos MPI a crear.

Al finalizar, “wrf.exe” habrá creado 1 archivo que contiene el pronóstico modelado. Este
archivo se llama “wrfout_d<número de dominio>.<fecha>” (por defecto, si es que no se
modificó en el namelist.input).

4 WRF en YAKU
Los pasos necesarios para ejecutar el modelo WRF en el cluster, si bien son los mismos
anteriormente explicados, se necesitan realizar unos cambios a ellos.
 _______________________________________________________________________
En primera instancia, se debe tener en cuenta que el cluster utiliza los llamados “módulos
de entorno” y un administrador de colas de trabajo para los diferentes usuarios que hacen
uso del cluster.

Debido a esto, para enviar a la cola de trabajos una corrida del wrf, es necesario agragarla a
la cola y esto se hace a través de la elaboración de un script.

4.1 Creación del script de trabajo

Desde la carpeta HOME del usuario crearemos una carpeta para la corrida que se desea
modelar. En este ejemplo práctico, utilizaremos un usuario de prueba llamado “test” para
realizar todos los pasos necesarios para modelar un día en particular.

Primero entonces creamos la carpeta de la corrida, en este ejemplo la llamaremos

“pruebaWRF”:

[test@master ~]$ mkdir pruebaWRF

[test@master ~]$ cd pruebaWRF/
[test@master pruebaWRF]$

Una vez que se tiene la carpeta, es necesario pegar dentro de la carpeta los archivos GFS
descargados con anterioridad desde la ubicación explicada en los capítulos previos de esta
guía. Con el comando “ls” podemos ver que archivos estan dentro de la carpeta de la
corrida.

[test@master pruebaWRF]$ ls
GFS_2018010918+000.grib2 GFS_2018010918+006.grib2 GFS_2018010918+012.grib2
GFS_2018010918+018.grib2 GFS_2018010918+024.grib2 GFS_2018010918+030.grib2
GFS_2018010918+036.grib2
GFS_2018010918+003.grib2 GFS_2018010918+009.grib2 GFS_2018010918+015.grib2
GFS_2018010918+021.grib2 GFS_2018010918+027.grib2 GFS_2018010918+033.grib2
GFS_2018010918+039.grib2

Una vez que tenemos los GFS, podremos crear el archivo que se envía a la cola de trabajo.
Esto lo hacemos con el programa nano de la siguiente manera:
 _______________________________________________________________________
[test@master pruebaWRF]$ touch wrf.sh
[test@master pruebaWRF]$ chmod +x wrf.sh
[test@master pruebaWRF]$ nano wrf.sh

Una vez dentro del programa nano, pegamos el siguiente contenido

#!/bin/bash

#SBATCH --job-name=pruebaWRF
#SBATCH --partition=normal

#SBATCH --ntasks=64
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=32
#SBATCH --exclusive

#SBATCH --mail-type=ALL
#SBATCH --mail-user=mail del usuario
################### Configuracion de WRF ###################

Donde:

--job-name: indica el nombre del trabajo para identificarlo

--partition: indica la partición a donde enviar el trabajo
--ntasks : indica el número de procesos MPI que se desean utilizar
--nodes : indica el número de nodos que se desean utilizar del cluster
--ntasks-per-node: indica la cantidad de procesos MPI por nodo
--mail-user : indica el correo al que se le enviarán todas las estadísticas de la corrida.

Una vez terminado, debajo de la última línea se deben agregar las siguientes líneas:

module load autotools

module load prun
module load ohpc
module load intel
module load impi
module load wrf/3.9

prun ./geogrid
prun ./ungrib
prun ./metgrid
prun ./real.exe
prun ./wrf.exe
 _______________________________________________________________________
Es necesario que dentro de la carpeta de la corrida se encuentren los namelist tanto de
WPS como de WRF.

4.2 Ejecución de WRF

Una vez terminado el script, se debe enviar a la cola de trabajos de SLURM (que es el
administrador de cola de tareas del cluster). Esto se hace con el comando “sbatch”

[test@master pruebaWRF]$ sbatch wrf.sh

Y saldrá un mensaje como el siguiente:

Submitted batch job 713 (713 es el ID del trabajo, este número siempre será diferente)

Y el modelo ya se estará ejecutando. Se puede corroborar su estado con el comando

“squeue”

[test@master pruebaWRF]$ squeue

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
713 normal pruebaWRF test PD 0:10 2 c1,master

4.3 WRF sobre Infiniband

En el cluster YAKU del LH-CETA se cuenta con conectividad Infiniband QDR de 40 Gb/s
para trabajos sobre MPI. Por defecto, esta es la conexión a utilizar por las librerías MPI
instaladas en el cluster.

En caso de querer ejectuar el modelo a través de LAN TCP, es necesario modificar el valor
de una variable de entorno llamada “I_MPI_FABRICS” al valor “tcp”:

[test@master pruebaWRF]$ export I_MPI_FABRICS=tcp

En caso de querer regresar a Inbiniband, solo basta con quitarle el valor a la variable
anterior:

[test@master pruebaWRF]$ unset I_MPI_FABRICS