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.

Presentación del tema: "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."— Transcripción de la presentación:

1 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

2 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

3 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

4 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

5 Se elige la batimetría, en este caso se utilizó la batimetría de http://onearth.jpl.nasa.gov/ con resolución de ¼ de grado

6 Se requiere también la línea de costa, se tomó de: http://www.ngdc.noaa.gov/mgg_coastline/mapit.jsp

7 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

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

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

10 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

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

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

13 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 ( http://iridl.ldeo.columbia.edu/SOURCES/.CARTON-GIESE/.SODA/.v2p0p2-4 ) 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

14 Simple Ocean Data Assimilation (SODA)

15 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

16 Interpolando Malla 3-D de SODA a ROMS TEMPERATURASSH

17 Interpolando Malla 3-D de SODA a ROMS UV

18 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”

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

20 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

21 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

22 SODA ORIGINALINTERPOLACIÓN A ROMS

23 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 http://data.ecmwf.int/data/d/era40_daily/ 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

24 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

25 Componente meridional del viento, en ERA-40 y ROMS

26 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

27 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.

28 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. https://www.myroms.org/wiki/index.php/Options

29 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.

30 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

31 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

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