IV Simposio Nacional de Predicci≤n

Memorial "Alfonso Ascaso"

Madrid 15-19 Abril 1996

I.N.M.

En esta comunicación se tratará de dar a conocer las características generales del montaje operativo del sistema de predicción HIRLAM/INM, tanto desde el punto de vista informático (esquema de la cadena operativa) como del meteorológico: tipo de datos que se utilizan y su preproceso, estadísticas de datos asimilados y rechazados por el preproceso y el análisis, tiempo de corte especificado para la asimilación de datos, condiciones de contorno que se emplean en cada pasada, horas a las que están disponibles las salidas de los modelos para los diferentes usuarios, campos meteorológicos disponibles, qué productos se elaboran a partir de estas salidas, estadística de fallos y causas, archivo histórico de las salidas del modelo, resolución y área, etc.

1.    Introducción.

El sistema de predicción actualmente operativo en el INM, consta de un modelo de área limitada llamado HIRLAM (High Resolution Limited Area Model) desarrollado por los Institutos Meteorológicos de Suecia, Noruega, Finlandia, Dinamarca, Holanda, Islandia e Irlanda, con la colaboración de Francia y la posterior incorporación de España. Todo el código de este modelo se encuentra recogido en un Sistema de Referencia, el cual se halla almacenado en el ordenador del Centro Europeo de Predicción para el Plazo Medio. Este Sistema es actualizado cuando se ha realizado alguna mejora en el modelo y ha sido aceptada por el grupo HIRLAM; el miembro del grupo encargado de esta tarea lo comunica al resto de las personas del grupo por medio de e-mail. Una vez recibida la comunicación, se recupera del Sistema de Referencia solamente aquella parte afectada por la modificación (programa de comandos, librería de Fortran) y se trae al ordenador del INM para efectuar la pruebas pertinentes en el Servicio de Predicción Numérica, antes de ser puesta en explotación

2.    Características generales del ordenador Cray-C90.

Este ordenador trabaja con el sistema operativo UNICOS (Unix de Cray) y consta de 4 procesadores vectoriales. Tiene una memoria principal de 1Gb.(1024 Mb.) y una secundaria de otro Gb. Su capacidad teórica de cálculo es de 1000 millones de operaciones en coma flotante por segundo (1 Gflop.) por cada procesador, aunque realmente, esta velocidad nunca se alcanza pues está calculada para condiciones ideales de máquina y código.

El ordenador Fujitsu-M382 ha sido sustituido por el Cray-C90 en la misión de efectuar la pasada operativa del modelo de predicción numérica en el INM, aunque este último sigue estando operativo para otras tareas (sistema SAIDAS, Base de Datos de Climatología, etc.), si bien, su completa sustitución por otro u otros ordenadores está próxima. En su día, fue el ordenador de procesadores escalares de mayor potencia de cálculo de los instalados en España, pero para poder satisfacer las necesidades surgidas debido a los avances en el campo de la predicción numérica (mayores resoluciones, mejores parametrizaciones, modelos no hidrostáticos, etc.), se hacían necesarios ordenadores cada vez mas potentes. Este el caso del ordenador Cray-C90, el cual dispone de unos procesadores llamados vectoriales, los cuales, gracias a su organización de la memoria central y a la forma de almacenamiento de vectores y matrices en memoria, pueden conseguir una velocidad de cálculo impensable en ordenadores escalares. Bien es verdad que es necesario programar siguiendo unas ciertas normas, así como utilizar herramientas de optimización del código para detectar zonas donde el rendimiento no sea el esperado, pues un ordenador vectorial es muy rápido cuando "vectoriza", pero es más lento que uno escalar si el código es completamente escalar. Como ejemplo de esto podemos decir que el módulo de predicción del antiguo LAM de 0.91 grados de resolución, tardaba 90 minutos de CPU en el Fujitsu, mientras que en el Cray- C90 tarda 6 minutos, con el código convenientemente vectorizado. Sin embargo, con el código exactamente igual que en el Fujitsu, tardaba más que éste.

Además de preparar específicamente el código para que vectorize aquellos bucles que nos interesan, es posible, en algunos casos, prepararlo para que todos los procesadores estén trabajando al mismo tiempo sobre la misma tarea, con lo que se consigue que trabajen en paralelo, mejorando aún más el rendimiento de la máquina. El único problema es que no todo el código es susceptible de ser paralelizado, pero en el HIRLAM, la parte de la física si lo es, reduciéndose mucho el tiempo de cálculo. Este trabajo en paralelo lo lleva a cabo el ordenador compartiendo la memoria entre todos los procesadores. En un futuro cercano y debido a las exigencias de mayor potencia de cálculo para implementar la asimilación variacional cuatro dimensional, estos ordenadores vectoriales serán sustituídos por ordenadores con procesadores masivamente paralelos, los cuales constan de un gran número de procesadores que trabajan en paralelo en una misma tarea, pero con memoria distribuida.

3.    Modelo operativo en el I.N.M.

Desde el mes de febrero de 1995 se encuentra operativa en el I.N.M. la versión del modelo HIRLAM con resolución horizontal (distancia entre dos puntos consecutivos de la rejilla) de 0.5. de latitud, lo que equivale en nuestras latitudes a unos 40 kilómetros. También tenemos operativa desde septiembre del mismo año otra versión del mismo modelo, pero con resolución de 0.2. de latitud (unos 18 kilómetros en nuestra latitudes). En cuanto a resolución vertical, ambas versiones tienen 31 niveles, en coordenada híbrida (coordenada sigma en los niveles cercanos al suelo y coordenada p en los niveles mas altos).

En la tabla 1 se pueden observar las coordenadas del área de ambas versiones, así como el número de puntos de la rejilla.

Las variables básicas del modelo son: temperatura, componentes U y V del viento, presión, humedad específica y cantidad de agua de nube.

El código del modelo está escrito en Fortran 77. En la tabla 2 podemos apreciar el número aproximado de líneas de código de que consta toda la cadena del sistema HIRLAM/INM.

El módulo ejecutable del modelo tiene un tamaño de 31.7 Megawords y el del análisis de 0.85 Megawords (cada palabra consta de 64 bits).

4.    Cadena operativa.

4.1.    Inicio.

Cuatro veces al día, a horas UTC prefijadas, el operador de consola lanza en el ordenador Fujitsu M382 un trabajo de extracción de boletines procedentes del GTS (Global Telecomunication System), que han llegado al INM a través del ordenador Zipi de Digital. Cuando el trabajo ha terminado, se envía por el canal que une los ordenadores Fujitsu y Cray un fichero de control para que un programa iniciador (starter) arranque en la cola de procesos hirstart del Cray, el programa Pasada (de comandos Unix) que desencadena la pasada operativa del sistema de predicción HIRLAM/INM.

En la tabla 3 podemos ver las horas UTC a las que se lanza la pasada.

Aunque se hacen los cortes cuatro horas antes de cada pasada esto es para efectos estadísticos de llegada de partes, pues el modelo toma solamente aquellos partes que corresponden a 3 horas antes y 2 horas después de la hora UTC de la pasada.

4.2.    Preparación.

El programa Pasada lanza a su vez otros programas auxiliares que tienen la misión de declarar los nombres de todos los directorios que se van a usar, calcular todas las horas y fechas que se van a utilizar por el resto de programas, definir constantes, etc. Se exportan todas estas variables para ser empleadas por el resto de programas de la pasada. Seguidamente se lanza el programa Hirlam_OPR, el cual lanza otros programas cuyas misiones son las siguientes: generar espacio en los discos magnéticos del ordenador borrando aquellos ficheros de la pasada anterior que no son necesarios para la actual, así como los ficheros de salidas de control del preproceso y postproceso; comprimir aquellos ficheros que no se van a necesitar por algún tiempo; seleccionar el campo previo que va a usar el modelo ( normalmente se utiliza la predicción para 6 horas de la pasada anterior del propio modelo, pero si la pasada ha abortado, se toma como campo previo la predicción de la hora correspondiente del modelo del Centro Europeo); copiar ficheros para experimentos; lanzar el preproceso de datos, el análisis, la integración y el postproceso del modelo.

4.3.    Preproceso de datos.

Una vez terminada la preparación del entorno, se lanza el programa Prepro, el cual desencadena el preproceso actual de datos (es provisional hasta que sea implementado el preproceso para todo el INM) del sistema HIRLAM/INM.

La primera acción que realiza es la de transferir al Cray desde el Fujitsu, a través del canal, el fichero de observaciones en formato mensaje que corresponde a la pasada (si hay problemas con el canal, se intenta por ftp y si también hay problemas, se aborta la pasada). Una vez que las observaciones están en los discos del Cray, se lanza el programa Tokida, el cual separa todos los boletines en seis tipos (satob, synop, airep/amdar, pilot, buoys y temp), codifica los mensajes en bufr y los coloca en unos ficheros pseudo indexados, los cuales simulan una base de datos. Por último, hace una extracción de datos de estos ficheros y los almacena en un único fichero, el cual es colocado en el directorio adecuado para ser utilizado por el modelo. Seguidamente, lanza los programas de control de partes (estadísticas de horas de llegada de partes, control del número de partes procesados, etc.)a la cola de procesos hirproc del Cray. A continuación, si la pasada es la correspondiente a las 00Z o a las 12Z, se lanza el programa Hlco, el cual tiene como primera tarea traer a los directorios de explotación 12 ficheros con las predicciones de 6 en 6 horas (hasta H+72) del modelo del Centro Europeo (llegadas al INM a través de la diseminación automática); como segunda tarea tiene la de interpolar estas predicciones desde 1.5. de resolución (se traen a esta resolución desde el CEPPM para que los ficheros sean mas pequeños y tarden menos en llegar) hasta la resolución del HIRLAM/INM(0.5), ya que van a servir como condiciones de contorno para esta versión del modelo. Si la pasada del HIRLAM/INM es la de las 00Z, las predicciones del modelo del CEPPM que se traen son las de la pasada de 12Z del día anterior y servirán también de condiciones de contorno para la pasada HIRLAM/INM de las 06Z. Si la pasada del HIRLAM/INM es la de las 12Z, se traen las predicciones del CEPPM de la pasada de 00Z del día de la fecha, las cuales servirán también como condiciones de contorno para la pasada HIRLAM/INM de las 18Z. Si la pasada HIRLAM/INM es la de las 06Z o la de las 18Z, desde el programa Prepro se comprueba que el modelo dispone de las condiciones de contorno necesarias para la pasada, si no se encuentran disponibles, se lanza el programa Hlco. En el supuesto de que hubiese habido algún problema con la línea con el CEPPM y no estuviesen disponibles las condiciones de contorno predeterminadas a la hora de efectuar una pasada, automáticamente el modelo toma las correspondientes a la pasada anterior del CEPPM. Este es el motivo de traer predicciones hasta H+72, para tener de margen un día entero para dar lugar a que lleguen las predicciones nuevas en caso de problemas. La interpolación de las condiciones de contorno se lanza a la cola de procesos hirlam.

4.4.    Tiempo de corte en la asimilación de datos.

En la tabla 4 podemos ver las horas UTC a las que se hace el corte en la asimilación de datos.

La hora de corte se ha tomado teniendo en cuenta dos cosas: la primera es que cuantos más boletines lleguen (sobre todo de sondeos) mejor para el análisis, por tanto, cuanto más se retrase esta hora, más boletines habrán llegado al INM; la segunda es que, cuanto antes comience la pasada, antes dispondrán los predictores operativos de las salidas del modelo. Por tanto, para establecer la hora de corte hay que llegar a un compromiso entre estas dos cuestiones. Para ello, se hace una estadística de horas de llegada de partes, aunque lo más importante es determinar a qué estaciones pertenecen los partes o boletines que llegan tarde y si esto ocurre sistemática o esporádicamente. Esto tiene mucha importancia en la zona SW de la rejilla de nuestro modelo (Océano Atlántico), pues suele haber pocos datos y si éstos llegan tarde, el análisis no será todo lo bueno que podría ser.

En la tabla 5 podemos apreciar, para la pasada de las 00Z desde Enero a Marzo de 1996, el número medio de partes que han llegado antes y después de la hora de corte, comparados con los que hubiesen entrado en el análisis si se hubiese retrasado 10 minutos esta hora.

Se observa que retrasar la hora de corte no supone mejorar mucho el número de partes que llegan, es decir, que los que llegan con retraso lo hacen en una cantidad de tiempo superior a los 10 minutos. Teniendo en cuenta, además, que el porcentaje de partes llegados antes de la hora de corte actual es muy alto, no compensa retrasar esta hora. Sí compensaría si los datos que faltan fuesen mayoritariamente de la zona citada anteriormente. Así, un estudio realizado para las cuatro pasadas diarias de todo el año 1995 y lo que llevamos de 1996, para determinar si es muy alto el número de sondeos de esa zona que se pierden por hacer el corte a las horas actuales, nos indica que si hubiésemos retrasado 10 minutos la hora de corte, hubiesen entrado 75 sondeos más (¡en 15 meses¡), y más aún, para poder recoger la mayoría de los sondeos de esa zona que llegan tarde, deberíamos retrasar la hora de corte más de 30 minutos, cosa que los predictores rechazan de plano, sobre todo en esta época del año en la que la hora oficial lleva dos horas de adelanto a la hora de la pasada y la premura de tiempo para realizar los pronósticos se hace más patente.

En la tabla 6 podemos ver, para un total de 12 estaciones de radio sondeos, el número de sondeos perdidos con la hora de corte actual y los que se hubiesen perdido si esta hora se hubiese retrasado 10 minutos.

Hay que hacer notar que la mayoría de sondeos españoles perdidos corresponden a la estación de Zaragoza, ya que, al parecer, siguiendo correctamente las normas al respecto, si el sondeo no llega a los 100hp., lo repiten, con lo que en ocasiones, no entra en la hora de corte.

4.5.    Asimilación de datos y análisis.

Una vez terminado el preproceso de datos, se lanza el programa Start, que define directorios y constantes que va a utilizar el modelo y, a su vez, lanza otros programas de comandos mediante los que crea los directorios de trabajo, prepara las librerías Fortran del sistema HIRLAM, prepara la estrategia respecto de las condiciones de contorno (determina qué condiciones de contorno se necesitan y las interpola) y lanza el programa Analyse, que inicia el análisis del sistema HIRLAM/INM(0.5). Las observaciones le llegan al análisis en bufr, pero las necesita en un formato determinado (Analysis Observation File), por lo que ejecuta el programa maof64.x, el cual hace un primer control para rechazar las observaciones que están fuera del área y del intervalo horario que corresponde a la pasada (tres horas por delante y dos por detrás de la hora UTC). Una vez se dispone del fichero AOF, se ejecuta el programa analyse64.x, el cual realiza el análisis del sistema HIRLAM.

En la tabla 7, podemos observar el número medio de partes durante 1995, que han sido procesados por el preproceso, el programa maof64.x y el análisis. La gran diferencia que se observa entre el número de partes que entran al preproceso y los finalmente aceptados, estriba en que se asimilan en un principio datos procedentes de todo el globo, con lo que posteriormente van a ser rechazados por no pertenecer al área HIRLAM/INM.

Cuando ha terminado el análisis, se escribe la salida en coordenada híbrida, en un fichero en formato grib, el cual es postprocesado para pasarlo a coordenada p. Este fichero contiene los campos siguientes: temperatura, geopotencial, componentes meridional y zonal del viento y la humedad relativa, para los niveles de 1000, 925, 850, 700, 500, 400, 300, 250, 200, 150 y 100 hp., más los campos de superficie: temperatura a 2 metros, componentes meridional y zonal del viento a 10 metros, geopotencial, presión al nivel del mar, presión al nivel de la estación y humedad específica.

4.6.    Integración del modelo.

Después de terminado el análisis, comienza la integración del modelo ejecutando el programa hlprog64.x. El paso de tiempo está fijado en 180 segundos, con lo que cada 60 pasos (cada 3 horas), se escribe un fichero postprocesado (con los campos en coordenada p a partir del fichero con los campos en coordenada híbrida), en formato grib, con los campos de temperatura, geopotencial, componentes U y V del viento y humedad relativa, para los niveles de 1000, 925, 850, 700, 500, 400, 300, 250, 200, 150 y 100 hp., más los campos de superficie: temperatura a 2 metros, componentes meridional y zonal del viento a 10 metros, geopotencial, presión al nivel del mar, presión al nivel de la estación, humedad específica, precipitación convectiva, precipitación a gran escala, precipitación total, nubosidad total y agua líquida integrada en la vertical.

Así, con salidas cada 3 horas, se llega a las 48 horas en las pasadas de 00 y 12Z y a las 24 horas en las de 06 y 18

4.7.    Postproceso para predictores operativos.

En cuanto se genera el fichero correspondiente a un alcance de predicción, se lanza el postproceso para ingestión de campos en el sistema SAIDAS y salida gráfica en papel, de tal manera que cuando la integración del modelo termina, si el ordenador Fujitsu no está saturado, solamente queda un alcance o dos por ingestar y un alcance por salir en papel por una impresora láser. En cuanto termina la integración del modelo, se lanza el archivo histórico y el postproceso para el resto de usuarios. Se archivan los ficheros en coordenada híbrida (sin postprocesar) siguientes: en las pasadas de 00 y 12Z, el fichero de análisis, el de análisis inicializado y los ficheros de predicciones de alcance par (H+6, ..., H+48); en las pasadas de 06 y 18Z, solo se archivan los dos ficheros de análisis y el fichero de predicciones de alcance H+6, que servirá como campo previo si posteriormente se desea repetir alguna pasada.

El proceso que realiza la ingestión en el sistema SAIDAS se lanza a la cola de procesos hirdisp, y el que lanza la salida gráfica, a la cola hirgraf.

Hay que hacer notar que está a punto de ponerse en explotación la salida gráfica del modelo a través de una estación de trabajo, en lugar de hacerlo desde el Cray, para optimización de recursos, quedando el método actual como alternativa por si hubiese algún problema con la red local.

4.8.    Postproceso de usuarios.

Al mismo tiempo que se lanza el archivo histórico, se lanzan las aplicaciones para usuarios: salidas para Defensa, archivo de campos para Predicción Estadística, verificación del modelo frente a su análisis, preparación de campos en coordenada sigma para el modelo MEDIA de difusión de contaminantes, salida gráfica de Meteogramas y Sondeos previstos, archivo (si procede) de los resultados de la verificación mensual del modelo frente a las observaciones y frente al análisis. Todos estos procesos se envía a la cola de procesos hirproc.

4.9.    Modelo de 0.2 grados de resolución.

Cuando ha terminado la integración del modelo de 0.5 grados de resolución, se lanza la versión de 0.2 grados de resolución, que utiliza como condiciones de contorno las predicciones de 3 en 3 horas del modelo de 0.5. Como campo previo utiliza su propia predicción de alcance H+6 de la pasada anterior, pero si ésta no terminó con éxito, utiliza las predicciones del modelo del CEPPM, convenientemente interpoladas.

El montaje es el mismo que para la otra versión del modelo, pero no lleva preproceso de datos propio, sino que utiliza el fichero de observaciones generado ya para el análisis de la versión de 0.5 grados. Todas las pasadas tienen como alcance máximo de las predicciones 24 horas. Solamente se ingestan en el sistema SAIDAS los campos de superficie, no campos de altura, e igual ocurre con la salida gráfica. Se archivan todos los ficheros en coordenada híbrida generados en las pasadas de 00 y 12Z, pero solamente los análisis y la predicción de H+6 para las pasadas de 06 y 18Z.

5.    Tiempos.

En la tabla 8, podemos observar el tiempo que tarda el ordenador Cray-C90 en realizar las tareas de interpolación de condiciones de contorno, análisis e integración del modelo (para un alcance máximo de 24 y de 48 horas), para cada una de las versiones operativas. El tiempo de cálculo está representado por TC, el tiempo de espera por TE, el tiempo real por TR (este tiempo viene dado en minutos, los otros en segundos)y por FC se representa el llamado factor de concurrencia de procesadores, que nos da idea del paralelismo conseguido en cada proceso (cuanto más se acerque a 4, que es el número de procesadores, más eficiente habrá sido el ordenador). El tiempo real se consigue sumando el tiempo de cálculo más el de espera, pasándolo después a minutos y dividiendo por el factor de concurrencia.

En la tabla 9 tenemos el tiempo real, en minutos, que se tarda en cada uno de los diferentes pasos de la cadena operativa. Al tiempo que se muestra, hay que

añadir 5 minutos aproximadamente, desde que el operador de consola arranca la pasada hasta que el ordenador Cray-C90 recibe la orden de comienzo al tener disponibles ya las observaciones en el ordenador Fujitsu.

6.    Estadística de fallos.

En ocasiones, la pasada operativa no llega a su fin. En este caso, no se archivan los campos del análisis o de la predicción que se haya podido alcanzar. Las causas de que aborte la pasada operativa son varias, por citar algunas: avería en la línea que une al INM con el CEPPM (no habrá condiciones de contorno), problemas con la cuota de espacio en disco (no se podrán escribir los ficheros de salida), problemas de ruido en la integración del modelo (inestabilidad computacional), error en la sintaxis de algún programa que se modifica o se pone operativo (este error de montaje puede hacer abortar toda la pasada si es un programa clave), problemas con las colas de trabajos del ordenador (no se ejecutarán los programas), problemas con el análisis (si no hay análisis no comienza la integración del modelo), avería en el ordenador Fujitsu (no habrá observaciones), corte del fluído eléctrico (una caída no programada del ordenador Cray puede dar lugar a problemas a la hora de arrancarlo de nuevo), ficheros de condiciones de contorno contaminados (habrá un error a la hora de hacer la interpolación), problemas de memoria o del sistema de entrada/salida del ordenador Cray, etc. Como vemos, son muchos y muy variados los motivos que pueden hacer abortar la pasada, aunque, por suerte, cada vez esto ocurre con menor frecuencia, pues hay errores que, una vez detectados, se les pone solución y ya no vuelven a ocurrir. Otros, sin embargo, su ocurrencia es aleatoria e imprevisible y, por tanto, de muy difícil solución. En la tabla 10 podemos observar la estadística de fallos de la pasada operativa del modelo de 0.5 grados de resolución. Todos los orígenes de fallos citados anteriormente los hemos reducido a cuatro grandes bloques: problemas informáticos, de montaje, del análisis y del modelo. El número de fallos de montaje es normal que sea bajo, puesto que hasta que no se asegura el funcionamiento de una aplicación o programa, éste no se pone operativo y, por tanto, los errores por este motivo solamente pueden venir por un error de sintaxis, pero como se pone en operación a horas en las cuales el personal encargado del mantenimiento de la cadena está presente, el problema se detecta inmediatamente y no hay lugar a la pérdida de una pasada completa. Como podemos ver, el mayor número de fallos informáticos se produjo al principio de todo. Esto también ocurrió con el análisis y el modelo. Una vez detectados los problemas, aquellos que tenían solución se solventaron fácilmente, pero otros no la tenían (inestabilidad computacional, análisis) por lo que en un primer momento hubo que montar alternativas (p.ej, si era el análisis lo que fallaba por culpa de algun tipo concreto de observaciones, se lanzaba automáticamente de nuevo sin ese tipo de observaciones; si era el modelo el que tenía inestabilidad computacional, se lanzaba de nuevo, pero con la subrutina de Kuo mas la COND, para la convección, en lugar de la de Sundqvist), así, podemos ver que a partir del mes de Junio ya no hay apenas fallos, aunque durante Julio, Agosto y Septiembre, el número de entradas alternativas fué alto. Sin embargo, a finales de Septiembre se puso en explotación un esquema implícito de la difusión horizontal, lo cual aseguraba la estabilidad computacional. Como se puede ver, el número de fallos en los últimos meses del año fué nulo. Para el modelo de 0.2 grados de resolución, el número más alto de fallos se debe al fallo en el modelo de 0.5 grados, ya que nutre a éste de condiciones de contorno y si no hay salidas de este modelo no habrá condiciones de contorno.

Tabla 10: Estadística de fallos de la pasada operativa del modelo de 0.5 grados de resolución.

     Referencias.

Del Río,P. 1995. Documentación de la pasada operativa en el I.N.M. Nota técnica número 49 del Servicio de Predicción Numérica.

Indice General