Regional Ocean Modeling System (ROMS) Configuración de un caso realista para el Pacífico del Este (tehuano) Estancia en Rutgers, University, N.J. Fernando Oropeza Rosales Ciudad Universitaria Agosto de 2008 Ciudad Universitaria Agosto de 2008

En esta sección se discute la generación de archivos de entrada en cuatro puntos: 1.Malla 2-D (Dominio horizontal) y 3-D coordenadas “S” 2.Archivo de Condiciones Iniciales 3.Archivo de Condiciones de Frontera 4.Archivos de forzamientos atmosféricos para las siguientes variables: Precipitación Radiación Solar de Onda Corta Radiación Solar de Onda Larga I) Archivos de entrada que se requiere generar

Archivos de forzamientos atmosféricos, continuación…. Temperatura del Aire Componente zonal del viento Componente meridional del viento Humedad Relativa Presión atmosférica en la superficie

I.1. Generando la Malla 2-D Se elige el dominio procurando conservar la ortogonalidad en la malla Se requieren las coordenadas de las cuatro esquinas

Se elige la batimetría, en este caso se utilizó la batimetría de con resolución de ¼ de grado

Se requiere también la línea de costa, se tomó de:

Con las coordenadas de las cuatro esquinas, la batimetría y línea de costa de utiliza “Seagrid” para interpolar la batimetría y generar la primera versión de la máscara Tierra-Mar

Se utiliza “EditMask” para editar la máscara generada automáticamente con Seagrid y mejorarla

Factor “R” y suavizado de la batimetría, umbral recomendado de R < 0.4

Construyendo la Malla 3-D coordenadas “S” Se eligieron parámetros de control que permiten concentrar más niveles sigma en la superficie, concentra 25 niveles en los primeros 1000 metros 30 Niveles THETA_S=8 THETA_B=0 TCLINE = 50

Coordenadas sigma con 30 niveles, corte vertical a lo largo de y=22 THETA_S=8, THETA_B=0, TCLINE = 50

Coordenadas sigma con 30 niveles; corte vertical a lo largo de x=44 THETA_S=8, THETA_B=0, TCLINE = 50

I.2. Generando Archivo de Condiciones Iniciales Se utilizaron datos del Simple Ocean Data Assimilation (SODA). Se analizaron dos juegos de datos: Disponible al público a través de Internet accediendo a un servidor “Open Dap”, con 1 mes de resolución temporal ( ) Se obtuvo un total de 500 GB de datos con el mismo reanálisis pero con promedios cada 5 días, se tienen datos de salinidad, temperatura, altura de la superficie del mar y las componentes horizontales de velocidad en 40 niveles verticales

Simple Ocean Data Assimilation (SODA)

En un solo intervalo, por ejemplo el primer día del año que se va a simular Se extraen los datos de soda interpolándolos a la malla 3-D de ROMS para todas las variables

Interpolando Malla 3-D de SODA a ROMS TEMPERATURASSH

Interpolando Malla 3-D de SODA a ROMS UV

I.3. Generando Archivo de Condiciones de Frontera Se interpolan los datos a la malla 3-D de ROMS, como en el caso de las condiciones iniciales, pero a lo largo de todo el periodo a simular. De esos archivos se toma un “recorte” en las fronteras de la malla 3-D de ROMS, de modo que el archivo tendrá valores de todas las variables en los cuatro lados del dominio (norte, sur, este y oeste). Existen varias opciones para imponer condiciones de frontera, en este caso se utilizó la opción más sencilla “clamped”

SSH, en la frontera sur con dt=5 días a lo largo del año 1996

Variación de la componente U de la velocidad horizontal en la frontera Oeste, en 30 niveles verticales a cada 5 días a lo largo del año 1996

Tratamiento especial para los campos de velocidades Tanto en el caso de las condiciones iniciales, como en el caso de las condiciones de frontera es importante vigilar que las velocidades queden referidas a los ejes apropiados, en el caso de la aplicación Tehuano, se tuvieron que rotar, ya que la malla está inclinada 22° con respecto a los ejes de SODA

SODA ORIGINALINTERPOLACIÓN A ROMS

I.4. Forzamiento Atmosférico Se utilizaron datos del proyecto de reanálisis ERA-40 del “European Centre for Medium-Range Weather Forecasts” Disponible al público a través de Internet, con 6 horas de resolución temporal Se obtuvieron datos en un recorte comprendido entre 0 y 25 N y 80 y 120 W, generando archivos de un mes más dos días para evitar NaN’s que genera el sistema por error, solo se extrajeron las variables en superficie

I.4. Forzamiento Atmosférico continuación… En ROMS la malla de forzamiento no tiene que ser igual que la malla computacional, ya que ROMS se encarga de interpolar los datos de forzamiento RECORTE SOBRE ERA-40

Componente meridional del viento, en ERA-40 y ROMS

En esta sección se discuten 4 puntos a considerar en la preparación de la corrida: 1.Estructura de directorios sugerida 2.Compilando la aplicación haciendo uso de las “CPP Options” (archivo tehuano.h) 3.Corriendo la aplicación utilizando el archivo de configuración “tehuano.in” 4.Archivos de salida II) Preparando la corrida del modelo

II.1. Estructura de directorios sugerida Se sugiere utilizar una estructura de directorios que facilite la administración de las aplicaciones: El directorio de trabajo:/Projects/tehuano/ Dentro del directorio de trabajo se sugiere la presencia de dos directorios: /Data y /Forward En Data se sugiere poner todos los archivos de entrada: el archivo de la malla, el de condiciones iniciales, el de condiciones de frontera y todos los archivos de forzamiento. El directorio Forward se sugiere tenga dos nuevos directorios: /Compile y /Run En Compile se pondrán los archivos “build.sh” y “tehuano.h” que se utilizan para especificar detalles de compilación, en Run se guarda el ejecutable de la aplicación y el archivo “tehuano.in”, en este mismo directorio se generan todos los archivos de salida de la corrida.

II.2. CPP Options ROMS utiliza C preprocessor (cpp) durante la compilación para modificar el código del modelo, se puede interpretar como un modificador de las ecuaciones y expresiones que representan los procesos físicos en el modelo. Se debe generar un archivo con el nombre de la aplicación definido en el archivo “build.sh” y con la extensión.h, en este caso el archivo es “tehuano.h” en el Wiki de ROMS se puede consultar una lista de todas las opciones disponibles.

II.3. Corriendo la aplicación utilizando el archivo de configuración tehuano.in En este archivo se definen las características específicas de la aplicación, como el tamaño de la malla, el Dt, el número de pasos de tiempo de la corrida, la frecuencia con la que se grabarán datos en los archivos de salida, los parámetros que definen las coordenadas verticales, los nombres de los archivos de entrada en formato NetCDF, como son el archivo con la malla, el archivo con las condiciones de frontera y el archivo con las condiciones iniciales; el número y nombre de los archivos de forzamiento, entre otras cosas.

II.4. Archivos de salida Generalmente se generan 4 tipos de archivos y el número total depende de la configuración que se haya elegido en el archivo.in, los tipos de archivos son: 1.History.- En el que se guarda el estado instantáneo de la malla 3-D del modelo para todas las variables con cierta frecuencia. 2.Averages.- En el que se guarda el estado promedio de la malla 3-D del modelo para todas las variables con cierta periodicidad. 3.Diagnostics.- En el que se guardan valores promediados en el tiempo de cada término de las ecuaciones de momentum y trazadores

II.4. Archivos de salida, continuación… 4.Restart.- En el que se guarda el estado instantáneo de la malla 3-D del modelo para todas las variables con cierta frecuencia, diseñado para re-arrancar el modelo

SSH simulada con ROMS para la aplicación tehuano, durante 100 días