DESARROLLO DE UN CÓDIGO OPORTUNISTA Y SU … · Desarrollo de un código oportunista y su...
28
Desarrollo de un código oportunista y su aplicación a la mecánica de fluidos Enrique Gallego Abad ([email protected]) Escuela Técnica Superior de Ingenieros Aeronáuticos Universidad Politécnica de Madrid Tutor: Javier Jiménez Sendín Introducción Hoy en día, la herramienta básica de trabajo en la mayoría de las disciplinas de la ciencia son los ordenadores. No es distinta la Mecánica de Fluidos, en la que se da el caso, además, de que no han sido resueltas las ecuaciones que la gobiernan (salvo para casos muy particulares). La razón principal es que no existen recursos que permitan hacerlo en un tiempo razonable. No obstante, existen diversos problemas fluidodinámicos resolubles con la capacidad computacional actual que no han sido resueltos salvo por instituciones con supercomputadores y que podrían ser resueltos con los recursos computacionales de los que se disponen (sin llegar a usar supercomputadores) si se lograse una forma de aprovechar dichos recursos eficientemente. Existen en el mundo diversas tendencias cuyo objetivo final, al igual que en esta investigación, es poder aprovechar los recursos disponibles de la forma más eficiente posible. Esto podría permitir resolver grandes problemas numéricos sin necesidad de superordenadores, solamente conectando simples PC’s u otros recursos de los que se dispongan. Numerosos grupos de investigación pueden beneficiarse de estas técnicas de aprovechamiento de recursos para desarrollar proyectos que necesiten de gran capacidad computacional, sin necesidad de realizar fuertes inversiones en superordenadores.
Transcript of DESARROLLO DE UN CÓDIGO OPORTUNISTA Y SU … · Desarrollo de un código oportunista y su...
Desarrollo de un código oportunista y su aplicación a la
mecánica de fluidos
Enrique Gallego Abad ([email protected])
Escuela Técnica Superior de Ingenieros Aeronáuticos
Universidad Politécnica de Madrid
Tutor: Javier Jiménez Sendín
Introducción
Hoy en día, la herramienta básica de trabajo en la mayoría de las disciplinas de la ciencia son los
ordenadores. No es distinta la Mecánica de Fluidos, en la que se da el caso, además, de que no han
sido resueltas las ecuaciones que la gobiernan (salvo para casos muy particulares). La razón
principal es que no existen recursos que permitan hacerlo en un tiempo razonable.
No obstante, existen diversos problemas fluidodinámicos resolubles con la capacidad
computacional actual que no han sido resueltos � salvo por instituciones con supercomputadores �
y que podrían ser resueltos con los recursos computacionales de los que se disponen (sin llegar a
usar supercomputadores) si se lograse una forma de aprovechar dichos recursos eficientemente.
Existen en el mundo diversas tendencias cuyo objetivo final, al igual que en esta investigación, es
poder aprovechar los recursos disponibles de la forma más eficiente posible. Esto podría permitir
resolver grandes problemas numéricos sin necesidad de superordenadores, solamente conectando
simples PC’s u otros recursos de los que se dispongan. Numerosos grupos de investigación pueden
beneficiarse de estas técnicas de aprovechamiento de recursos para desarrollar proyectos que
necesiten de gran capacidad computacional, sin necesidad de realizar fuertes inversiones en
superordenadores.
El Código Oportunista desarrollado está orientado a realizar esta tarea: aprovechamiento eficiente
de los recursos computacionales.
La simulación numérica en la Mecánica de Fluidos
Los principios físicos fundamentales que rigen la mecánica del movimiento de un fluido se pueden
expresar mediante un sistema de ecuaciones diferenciales en derivadas parciales. Se ha dedicado
mucho esfuerzo a la búsqueda de una solución analítica de esas ecuaciones, pero debido a que este
sistema de ecuaciones es no lineal, solo ha sido posible encontrar soluciones analíticas para casos
sencillos.
La Mecánica de Fluidos Computacional se encarga de aproximar estas ecuaciones mediante
relaciones más sencillas de carácter algebraico, que puedan resolverse numéricamente empleando
operaciones elementales: suma, resta, multiplicación y división. Esta técnica, muy empleada en
otras ramas del conocimiento, se denomina discretización.
Debido a la forma en que se realizará esta aproximación, la solución resultará ser un conjunto de
valores correspondientes a las magnitudes físicas del flujo localizadas en un número discreto de
puntos del campo fluido. El volumen de datos que se requiere manejar de forma repetitiva para
hallar una solución numérica de un problema de mecánica de fluidos es generalmente tan alto, que
el desarrollo de la Mecánica de Fluidos Computacional en las tres últimas décadas ha seguido al de
los computadores digitales. Incluso hoy en día, la mayoría de los problemas de interés industrial no
pueden ser abordados satisfactoriamente.
La Mecánica de Fluidos Computacional en la actualidad
Notas históricas
Una de las primeras aportaciones a la Mecánica de Fluidos desde un enfoque computacional es la
debida al trabajo de Kopal (1947), que compiló tablas masivas de datos referentes a un flujo
supersónico alrededor de conos afilados, resolviendo numéricamente las ecuaciones que rigen el
2
problema. Los cálculos fueron realizados en un ordenador digital primitivo del Instituto
Tecnológico de Massachusetts. Sin embargo, la primera generación de soluciones numéricas
aplicando mecánica de fluidos computacional data de los años 50 y principios de los 60, ante la
necesidad de calcular flujos hipersónicos alrededor de vehículos de reentrada. Dichos flujos están
caracterizados por fenómenos físicos muy complicados, como son las reacciones químicas, que
combinados con las ecuaciones de la mecánica de fluidos hacen imposible obtener soluciones
analíticas incluso para las geometrías más sencillas.
La segunda generación de soluciones de la Mecánica de Fluidos Computacional, que hoy en día
sigue siendo representativa de la disciplina, proviene de la resolución de problemas de mecánica de
fluidos que son complejos por sí solos, sin necesidad de añadir ecuaciones adicionales. La única
posibilidad para resolver estos problemas es el uso de computadoras.
Algunos ejemplos de estos problemas son flujos con zonas subsónicas y supersónicas o flujos
viscosos en los que se requiere resolver las ecuaciones de Navier-Stokes para obtener soluciones
satisfactorias. Éste es el caso de la turbulencia. Esta segunda generación de soluciones surgió en los
años 70, al amparo del enorme crecimiento que experimentaron las prestaciones de los ordenadores.
La situación actual
El papel de la Mecánica de Fluidos Computacional en las ciencias y en la ingeniería se ha hecho tan
importante hoy en día que se puede considerar una tercera rama de la Mecánica de Fluidos, junto
con las ramas teórica y experimental, complementando y alimentándose de ambas. La Mecánica de
Fluidos Computacional cubre un amplio espectro de problemas, que se extiende desde la generación
de métodos de diseño en ingeniería hasta el cálculo detallado de soluciones de las ecuaciones de
Navier-Stokes, complementando los resultados experimentales. En un extremo, existen paquetes de
diseño para sistemas de tuberías que requieren tiempos de cálculo del orden de segundos en un
ordenador personal. En el otro, existen códigos que emplean cientos de horas de cálculo en los
superordenadores más grandes.
Los modelos teóricos que proporcionan soluciones analíticas en forma cerrada suelen obtenerse tras
simplificar las ecuaciones de Navier-Stokes, después de eliminar los términos menos importantes en
cada caso particular. De esta forma, las soluciones teóricas identifican los parámetros
fundamentales que rigen cada problema, y proporcionan información de la influencia de la
3
variación de dichos parámetros sobre el fenómeno físico que representan. Sin embargo, el campo de
aplicación de estos modelos teóricos está restringido a problemas muy sencillos, de escaso interés
práctico. La Mecánica de Fluidos Computacional permite extender el estudio detallado a problemas
más complejos y de mayor interés práctico.
Sin embargo, el aspecto más importante de la aplicación de la Mecánica de Fluidos Computacional
a la industria ha sido su impacto sobre los ensayos en túnel y en banco, debido a la rápida reducción
del coste de computación promovida por el gran incremento de las prestaciones de los ordenadores.
Hoy en día resulta más barato calcular numéricamente las propiedades de una aeronave que
medirlas en un túnel aerodinámico. De hecho, en la industria aeronáutica el diseño preliminar se
basa principalmente en cálculos realizados por ordenador, empleándose los ensayos en túnel para
afinar detalles en las fases finales de diseño. Esto era impensable hace años, cuando la totalidad de
la información empleada en el diseño provenía de ensayos en túnel.
Las ecuaciones de la dinámica de fluidos adimensionalizadas dependen de un gran número de
parámetros adimensionales, como son el número de Reynolds, el número de Strouhal, el número de
Prandtl, el número de Mach, etc... Los ensayos en túnel aprovechan aquellos casos en los que el
flujo depende de un número reducido de parámetros (uno o dos), realizándose ensayos en
geometrías semejantes a escala, seleccionando adecuadamente las propiedades del fluido para que
conserven los parámetros adimensionales de que depende el flujo. De esta manera, en base a la
semejanza dimensional, los resultados obtenidos en el ensayo serán aplicables al caso real que se
quiere estudiar una vez escalados convenientemente. El problema de estos ensayos experimentales
es que la mayoría de los flujos requieren varios parámetros adimensionales para su descripción, por
lo que resulta imposible preparar experimentos que verifiquen los principios de la semejanza
dimensional en estos casos. En particular, esto es lo que ocurre con los flujos a altos números de
Reynolds.
Otro inconveniente adicional de los ensayos consiste en la dificultad para realizar medidas
experimentales, bien porque el instrumento de medida perturba el campo fluido, porque no tenga la
precisión adecuada, porque el punto en el que se quiera medir sea inaccesible o por la dificultad de
medir una determinada variable del flujo con la tecnología actual. En principio todas estas
dificultades no existen en los experimentos numéricos.
4
Es muy importante señalar que en el ordenador se pueden llevar a cabo experimentos irrealizables
en el laboratorio. Por ejemplo, baste pensar en la dificultad técnica de imponer una condición de
contorno adiabática en un ensayo en laboratorio, frente a simular esa misma condición en un
ordenador. Incluso se pueden implementar condiciones de contorno exóticas, aplicar filtros o
representar las contribuciones de los distintos términos en las ecuaciones, a fin de identificar los
mecanismos físicos que gobiernan un determinado problema. Este último punto es sin duda el valor
más importante de la Mecánica de Fluidos Computacional en el campo de la investigación
fundamental.
Además, mientras que las simulaciones numéricas permiten obtener soluciones detalladas del
campo fluido, en los experimentos estas soluciones son difíciles de obtener, calculándose
parámetros globales del flujo como por ejemplo los coeficientes de sustentación, resistencia,
convección, etc...
Las razones anteriores, que justifican la incorporación de la Mecánica de Fluidos Computacional
como una nueva rama de la Mecánica de Fluidos, están condicionadas a la capacidad de resolver de
forma precisa las ecuaciones de Navier-Stokes, lo que es prácticamente imposible con los recursos
computacionales disponibles en la actualidad para la mayor parte de los flujos de interés industrial.
Fuentes de error de la simulación numérica
Las fuentes de error de la simulación numérica son tres, a parte del error de redondeo del
procesador.
�� Las ecuaciones diferenciales que se resuelven suelen tener aproximaciones o
idealizaciones, ante la dificultad inherente de la resolución numérica directa de las
ecuaciones de Navier-Stokes. Este aspecto es crítico en la resolución de flujos
turbulentos.
�� La discretización del problema produce errores de truncación.
�� En general, la resolución de las ecuaciones discretizadas se lleva a cabo mediante
métodos iterativos, que no proporcionan la solución exacta.
5
En principio, cuando las ecuaciones que gobiernan el flujo se conocen con exactitud, se pueden
alcanzar soluciones numéricas con el grado de precisión que se desee. Sin embargo, para un gran
número de problemas o bien no se conocen las ecuaciones o bien su resolución no es posible en el
presente. Este es el caso de algunos problemas relacionados con la combustión, los fluidos
multifásicos o la turbulencia. Incluso en el caso de que se conozcan las ecuaciones y puedan
resolverse con exactitud, es lícito pensar en algún modelo para disminuir el coste de la solución.
Para validar estos modelos es indispensable disponer de información experimental, aunque hoy en
día también se emplean métodos numéricos de alta precisión para esta tarea.
Los errores de discretización se pueden reducir empleando técnicas de interpolación más precisas,
lo que implica aumentar el tiempo de cálculo, o empleando discretizaciones más finas, lo que
aumenta el volumen de datos a procesar.
En la resolución de las ecuaciones discretizadas se suele llegar a un compromiso: los métodos
directos proporcionan soluciones exactas a estas ecuaciones, pero resultan muy costosos en tiempo
de cálculo. Los métodos iterativos son más rápidos, pero producen errores al detener el proceso de
iteración antes de que la solución converja a la solución exacta.
Por último, es importante tener en cuenta que para que la solución de una simulación de mecánica
de fluidos computacional sea correcta no es suficiente con que lo parezca. No hay que dejarse llevar
por las llamativas visualizaciones que proporcionan las simulaciones por ordenador. Cuanto más
crítico sea uno mismo con sus resultados menos críticos serán los demás.
Código Oportunista
La gran cantidad de datos que se generan en la resolución de problemas de flujos turbulentos a altos
números de Reynolds mediante simulación directa hace necesaria una potencia computacional
enorme para su postproceso. Esta tarea en sí es bastante sistemática, y dividida en partes podría ser
realizada por cualquier PC del Departamento. Partiendo de esta idea se inició un estudio de técnicas
de aprovechamiento de recursos.
6
En un principio se optó por realizar un estudio sobre la idoneidad de implementar Tecnología Grid
en colaboración con otros grupos de Mecánica de Fluidos. La conclusión fue que dicha tecnología,
en la fase de desarrollo en que se encuentra, no suponía una solución adecuada. Llegado a este
punto se decidió crear un código escrito en Fortran 77 bajo un sistema operativo tipo UNIX (en
particular Linux) que permitiese lanzar y monitorizar cualquier código paralelizable. De esta forma
surge el Código Oportunista destinado a mejorar el aprovechamiento de los recursos
computacionales de que dispone el área de Mecánica de Fluidos Computacional del Departamento
de Motopropulsión y Termofluidodinámica de la Escuela Técnica Superior de Ingenieros
Aeronáuticos.
Antecedentes del tema tratado
��Tecnología grid
La idea de desarrollar un código de este tipo, como ya se ha mencionado, surgió a partir de un
estudio previo sobre la idoneidad de implantar Tecnología Grid en el Departamento para:
�� disminuir los tiempos de proceso de los programas de resolución y postproceso de
problemas fluidodinámicos turbulentos.
�� tener la capacidad computacional necesaria para correr programas imposibles de correr
individualmente en cualquiera de los equipos actuales.
El resultado negativo de este estudio llevó a considerar otras alternativas de aprovechamiento de
recursos, decidiéndose por el código que aquí se presenta.
Se puede decir de forma básica que un ‘Grid’ es un conjunto de recursos computacionales
repartidos por todo el mundo y que son compartidos por una comunidad de usuarios bajo unas
reglas determinadas.
El concepto de ‘Grid’ surge de las siguientes consideraciones:
- gran cantidad de recursos de CPU no se usan durante largo tiempo.
- los PC’s actuales ofrecen altas prestaciones a bajo coste.
7
- cada ordenador conectado a Internet puede tener acceso al resto de ordenadores
conectados a la red.
- los proyectos científicos actuales necesitan de gran capacidad computacional para el
procesado de datos.
De este modo, interconectando una gran cantidad de ordenadores (potencialmente todos los del
mundo) y usando un software especial de gestión de recursos, denominado ‘middleware’, se puede
configurar un ‘Grid’ que genera un poderoso entorno computacional al que puede suscribirse
cualquier institución para correr sus programas más complejos.
��Seti@home
“Search for Extraterrestial Intelligence”, más conocido como SETI es una investigación científica
que trata de determinar si existe vida fuera de la Tierra.
Uno de los métodos utilizados en esta investigación es el de captar las señales de radio artificiales
procedentes de las estrellas a través de un telescopio situado en Arecibo (Puerto Rico). El gran
problema de este método es la generación de una enorme cantidad de datos imposible de procesar
con los recursos de la UC Berkeley. El proyecto SETI tampoco puede afrontar la adquisición de los
recursos computacionales necesarios, por lo que surge la idea del SETI@HOME que permite
participar a cualquier persona que posea un ordenador conectado a internet en el tratamiento de
datos.
La idea básica del SETI@HOME es tomar prestados los ordenadores de todas las personas que
deseen participar en el proyecto y enviarles cargas de trabajo cuando los propietarios no los estén
usando. Para ello es necesario que en cada ordenador colaborador esté instalado el programa de
SETI@HOME, el cual permite la recepción de datos vía internet, el proceso de tales datos y el
envío de los resultados vía internet al servidor de SETI.
8
Desarrollo y aplicación del Código Oportunista
El programa desarrollado es capaz de correr códigos paralelizables (denominados programas
esclavos) en los distintos ordenadores que tiene el Departamento (incluidos clusters y PCs) que
trabajen bajo sistema operativo tipo UNIX, como ya se ha mencionado.
Esta investigación se ha centrado en el desarrollo y aplicación de un código que permita realizar el
postproceso de los datos obtenidos de la resolución del flujo turbulento a altos números de
Reynolds entre dos placas planas mediante simulación numérica directa. En este problema se desea
conocer la cantidad y las propiedades de los torbellinos que se generan en el flujo a distintos
números de Reynolds� (Re�=950 y Re�=1880 han sido los empleados durante el desarrollo del
Código Oportunista). Al aumentar el número de Reynolds, aumenta el rango de escalas de
torbellinos presentes en el flujo turbulento, y con ello la cantidad de información.
El fin principal no es el de conseguir mejorar los tiempos de ejecución del programa esclavo, sino el
de poder ejecutar este programa en aquellas ocasiones en las que fuese imposible de correr con
cualquiera de los recursos del Departamento de forma individual, debido a la gran cantidad de datos
a manejar.
Lo primero que se va a hacer es presentar los dos programas de los que se va a estar hablando a lo
largo este texto:
��VORXY. Esta es la denominación del programa de postproceso de datos obtenidos en la
resolución del flujo turbulento entre dos placas planas a alto número de Reynolds. Éste es el
programa que ha servido de aplicación a la investigación desarrollada.
��MAESTRO. Así se denomina al programa de distribución y monitorización de tareas a los
distintos nodos de la red informática. Éste es el programa desarrollado en la investigación
que se ha realizado (Código Oportunista).
A continuación se va a explicar el funcionamiento básico del programa VORXY de postproceso de
datos, así como las modificaciones necesarias para que este programa pueda ser ejecutado bajo las � El número de Reynolds del que se habla Re� está basado en coordenadas de pared, no es el del flujo medio, cuyo valor estaría entorno a 25000 para el caso de Re�=950.
9
órdenes del programa MAESTRO. Además se explicará la estructura del programa MAESTRO y se
darán los resultados obtenidos durante la investigación.
VORXY. El postproceso de datos
El objetivo del programa es obtener en variables físicas los valores, en un instante de tiempo
determinado, de:
��Componentes de la velocidad.
��Componentes de la vorticidad.
��Derivadas de la velocidad respecto a las distintas direcciones.
��Otras variables empleadas en la identificación de torbellinos.
Se dispone de 24 archivos de datos (192 MB cada uno) correspondientes a la resolución del
problema a un Re�=950, y de 81 archivos de la resolución a Re�=1880 (1.6 GB cada uno). Cada
archivo contiene los datos del flujo turbulento del canal en un instante de tiempo determinado, es
decir, tras la consecución de varios pasos temporales.
La discretización espacial empleada en la simulación es mixta:
��Fourier. Se emplean desarrollos en serie de Fourier en las direcciones paralelas a la pared.
��Chebyshev. En la dirección normal a la pared se usan desarrollos en serie de Chebyshev.
Este hecho va a determinar la forma de actuar en el postproceso de datos. En efecto, en el código de
VORXY, escrito en forma serial, se encuentran dos bucles, uno que opera en planos paralelos a la
pared (denominado proceso K) y otro que lo hace en planos perpendiculares a la pared (denominado
proceso J). Es importante resaltar la dependencia entre ambos procesos, ya que es necesaria la
finalización del proceso K para que pueda iniciarse el proceso J.
10
Figura 1. Esquema del problema fluidodinámico resuelto.
Para ambos procesos se actúa de una forma similar: se va realizando el postproceso por bloques de
planos, en un número tal que la máquina sea capaz de hacerlo de forma eficiente. Estos números
(uno del proceso K y otro del proceso J) son parámetros a introducir inicialmente.
El resultado de la ejecución del programa VORXY sobre uno de los archivos de datos es un
conjunto de archivos que contienen las variables del flujo turbulento en el plano físico en un
instante de tiempo determinado.
Paralelización del código de VORXY
Para poder aplicar el programa MAESTRO al programa VORXY es necesario paralelizar el código
de este último de una forma adecuada.
Debido a estructura del código de VORXY, la paralelización es muy sencilla de realizar, basta
eliminar el “do” de los bucles y que la variable del bucle venga dada por una orden del programa
MAESTRO. Con esto se consigue que en lugar de un bucle de “n” pasos se tengan “n” subtareas.
Durante la explicación del código del programa MAESTRO se profundizará más en este hecho.
MAESTRO. Distribución y monitorización de tareas.
El programa MAESTRO se encarga de:
1. Conocer el estado de los nodos de la red.
2. Distribuir las subtareas por los nodos.
3. Realizar un seguimiento de las subtareas y actuar en consecuencia.
11
Para poder realizar dichas misiones es necesario conocer:
1. Direcciones IP de los nodos de la red.
2. Número de subtareas a realizar.
Además de los aspectos referentes exclusivamente a la escritura del código del programa
MAESTRO, es necesario que los recursos computacionales utilizados cumplan con ciertos
requisitos de homogeneidad. MAESTRO es un programa escrito en lenguaje Fortran 77 y
compilado con el g77 de Linux. El código tiene llamadas al sistema operativo necesarias para
realizar la distribución y monitorización de las subtareas, así como para controlar el estado de los
nodos de la red. Por todo esto, el programa necesita:
��Sistema operativo tipo UNIX (comunicación entre nodos mediante “rsh”)
��NFS
��NIS
Tras la explicación del programa MAESTRO se realiza una descripción más detallada de los
recursos computacionales utilizados en el desarrollo del código.
Código del programa MAESTRO � Código Oportunista �.
Se va a realizar una explicación del código del programa MAESTRO, de esta forma se logrará
entender el funcionamiento del mismo.
Existe un fichero “definición” en el cual, además de las variables propias del código Fortran, se
definen las direcciones IP de los nodos que el programa MAESTRO va a tener disponibles para
lanzar subtareas y el número de subtareas de los procesos K y J anteriormente mencionados.
Conviene aclarar aquí la denominación de tarea y subtarea:
��Tarea: cada uno de los archivos de datos es una tarea a realizar por MAESTRO (24 para
Re�=950 y 81 para Re�=1880).
��Subtarea: cada bloque de planos que se emplean en los procesos K y J. Su número se
fija a priori.
12
El código del programa MAESTRO se divide en dos grandes bloques, un primer bloque
correspondiente al lanzamiento y monitorización de tareas del proceso K y otro correspondiente al
proceso J. Esto se ha hecho así porque el número de subtareas de uno y otro proceso no tiene que
ser idéntico (normalmente es distinto), lo que da lugar a un dimensionamiento distinto de los
procesos. Salvo por esto, ambos bloques son similares en cuanto a su estructura, por lo que se
pasará a describir sólo uno de ellos. Se recuerda además que para cada tarea es necesario que
terminen todas las subtareas del proceso K para que puedan iniciarse las subtareas del proceso J.
En cada bloque del código se tienen los siguientes conjuntos de órdenes:
1. Bucle de tareas (engloba al resto de conjuntos).
2. Lanzamiento de subtareas a los nodos disponibles.
3. Control de subtareas (Monitorización).
4. Control del estado de los nodos.
5. Borrado de archivos temporales y preparación para la siguiente tarea.
En la Figura 2 se ha representado un esquema de bloques del código del programa MAESTRO en
el que se pueden apreciar los conjuntos de órdenes citados, que se explicarán más adelante.
El programa se ha corrido en el cluster Vulcano que se describirá más adelante; este cluster posee 4
nodos, cada uno de los cuales dispone de una partición de disco duro de 5 GB destinada al
almacenamiento de datos:
1. vulcano /home
2. vn01 /home01
3. vn02 /home02
4. vn03 /home03
Para el desarrollo del Código Oportunista (o programa MAESTRO) se ha usado únicamente el
cluster Vulcano. Ahora bien, en un futuro el código se ejecutará aprovechando todos los recursos
computacionales del Departamento que interesen.
13
TAREA 1
TAREA 2
TAREA 3
TAREA 4
��INICIALIZACIÓN DE VARIABLES
INICIO DEL BUCLE DE TAREAS
��CONTROL DE ESTADO DE NODOS
��LANZAMIENTO DE SUBTAREAS
��MONITORIZACIÓN DE SUBTAREAS
��CONTROL DE ESTADO DE NODOS
��LANZAMIENTO DE SUBTAREAS
��MONITORIZACIÓN DE SUBTAREAS
��BORRADO DE ARCHIVOS TEMPORALES ��PREPARACIÓN PARA SIGUIENTE TAREA
FIN DEL BUCLE DE TAREAS
��PARÁMETROS DEL CÓDIGO ��DEFINICIÓN DE VARIABLES
Figura 2. Esquema de los procesos realizados por el programa MAESTRO.
14
Durante la ejecución del programa, el cluster estaba libre de otras cargas de trabajo. Aunque esta no
es la idea, MAESTRO está pensado para aprovechar los pocos recursos libres que queden en un
cluster, sirve para comprobar el funcionamiento y los tiempos de ejecución de las tareas corridas
bajo las órdenes del programa MAESTRO.
Conjuntos de órdenes del código oportunista � programa maestro �
��Bucle de tareas. Está ideado para que realice el postproceso de todos los archivos que
se tengan para un mismo Re�. Los archivos, debido a su gran tamaño se guardan en un
ordenador de gran capacidad de memoria, no en los nodos en los que se va a correr el
programa. Por esto, la primera operación del bucle es “coger” la tarea (archivo) de dicho
ordenador a través de un rcp y copiarla en /home01.
rcp='rcp enrique@tinglao:'//DIRIN//arch tarea=' /home01/enrique/campos1880/' call system(rcp//tarea,status)
El bucle de tareas engloba al resto de conjuntos de instrucciones que se describen a
continuación.
��Control de estado de los nodos. Mediante llamadas al sistema operativo Linux, usando
las órdenes adecuadas, y empleando rsh para las comunicaciones entre nodos, se
determina:
1. %CPU: porcentaje total de CPU usada por cada nodo.
2. %mem: porcentaje total de la memoria usada de cada nodo.
3. Swap: identifica si con la carga dada al nodo se produce o no “swapeo”
do i=1,nnod rsh='rsh -n '//nodo(i) ps=' ps -A eo pcpu,pmem > '//RUTAOUT//carga(i)
call system(rsh//ps,status) if (status.ne.0) then est(i)=-1 endif enddo
15
Según los valores de las variables mencionadas y con unos criterios de estado
establecidos previamente se clasifican los nodos en: Libres, Ocupados o Caídos.
��Lanzamiento de subtareas. Se lanzan subtareas a aquellos nodos que hayan sido
clasificados como libres (tras lanzar una tarea a un nodo se vuelve a evaluar su estado).
La comunicación entre nodos se realiza mediante rsh.
do i=1,nnod if
(est(i).eq.0.AND.jpn(i).lt.2.AND.k.le.znjob) then write(ich,'(i2)') i write(kch,'(i3)') k write(controlch,'(i2)') control 100 if (zenv(k).eq.0) then jpn(i)=j pn(i)+1 rsh='nohup rsh '//nodo(i)//' time '
tarea=RUTA//'VORXY<hre.dat '//ich//kch//controlch//' &'
zenvn(k)=i call system(rsh//tarea,status)
��Monitorización de subtareas. Una de las partes más importantes del código es el
seguimiento de las subtareas hasta su finalización. En este conjunto de órdenes se busca
conocer para cada subtarea:
1. si ha sido lanzada
2. a qué nodo ha sido lanzada
3. cuánto tiempo lleva en ejecución
4. si ha finalizado
5. si ha sido “matada” externamente
16
A través de la pid (número propio de cada proceso que se ejecuta en un nodo) se puede
hacer un seguimiento de la subtarea que se está ejecutando. Mediante llamadas al
sistema se puede conocer información sobre cualquier proceso que esté corriendo.
Ciertas preguntas como si una subtarea ya ha sido lanzada y a qué nodo se responden
durante la fase de lanzamiento de subtareas, pues ahí se lleva una contabilización sobre
estos asuntos.
��Borrado de archivos temporales y preparación para siguiente tarea. Es la última
operación antes de terminar el bucle. En ella se borran los archivos temporales
generados durante ambos procesos (K y J), así como el archivo de datos que se grabó
inicialmente en /home01. Por último se procede a cambiar un archivo auxiliar de datos
que permite saber cuál es el nombre del archivo de la siguiente tarea a realizar.
El resumen del funcionamiento del programa MAESTRO, una vez determinados los nodos y el
número de subtareas para cada proceso, es:
1. Inicio de tarea P.
2. Lectura y grabación en /home01 del fichero TareaP.
3. Inicio del proceso K.
3.1. Lanzamiento y monitorización de subtareas.
3.2. Creación de ficheros temporales de datos en /home02 (a usar durante el proceso J).
4. Fin del proceso K.
5. Inicio del proceso J.
5.1. Lanzamiento y monitorización de subtareas.
5.2. Creación de ficheros de postproceso en /home03.
6. Borrado de archivos temporales.
7. Actualización de archivos auxiliares de información.
8. Fin de tarea P.
Repitiéndose el proceso hasta que se completen todas las tareas a realizar.
Para terminar con la descripción del programa MAESTRO cabe decir que el programa reside en
sólo uno de los nodos, y las comunicaciones con el resto se realizan a través de rsh.
17
Los recursos computacionales utilizados: Vulcano
Esta máquina pertenece al Laboratorio de Mecánica de Fluidos Computacional del Departamento de
Motopropulsión y Termofluidodinámica de la Escuela Técnica Superior de Ingenieros
Aeronáuticos.
En el presente apartado se describirán el hardware y software empleado por Vulcano y las
principales etapas del proceso de instalación y configuración de la máquina, insistiendo en la
finalidad que se busca de cara a la programación paralela con cada una de estas etapas. Es
importante destacar estos aspectos para dar a entender la proximidad del diseñador a una
arquitectura de esta clase, así como la gran flexibilidad de estos sistemas.
Se debe hacer ver aquí que durante el desarrollo de esta investigación no se busca usar Vulcano
como un cluster en sí, sino como 4 nodos independientes comunicados a través de una red Fast
Ethernet. El uso de Vulcano permitirá además, posteriormente, comparar los tiempos de ejecución
del programa VORXY corrido en paralelo y corrido como esclavo del programa MAESTRO.
Hardware
El sistema Vulcano consta de 4 nodos, uno utilizado como servidor y el resto como clientes, cada
uno de los cuales se caracteriza por:
��Procesadores Intel Pentium III Duales 500 MHz con 512 KB de memoria caché.
��384 MB de memoria RAM.
��9 GB de Disco Duro.
��2 Tarjetas de red para las redes de comunicación internas. El nodo servidor dispone de una
tarjeta de red adicional para las comunicaciones del cluster con el exterior.
��Unidad de CD-ROM 32x SCSI.
��Unidades de diskettes de 1.44 MB.
Además de los 4 nodos, el sistema consta de:
��1 red Fast Ethernet de ancho de banda 100 Mbits/s.
18
��1 red Scali de ancho de banda 640 Mbits/s.
��1 switch de comunicaciones para la red Fast Ethernet.
��1 Monitor, teclado y ratón para el nodo utilizado como servidor.
Software
Se ha instalado como sistema operativo Linux RedHat 6.1. Se pueden distinguir dos perfiles de
instalación, uno para el servidor y otro para los nodos. El disco duro o memoria secundaria se
divide, según cada uno de los dos perfiles, en distintas particiones que pueden ser consideradas
como pequeños discos duros dentro del principal, pero que no son estancos entre sí. Estas
particiones permiten mayor velocidad en la búsqueda de los datos. También proporcionan seguridad
en caso de que se dañe una parte del disco duro, pues sólo se verán afectadas aquellas particiones en
las que residan los sectores dañados.
La partición de arranque contiene la información necesaria para arrancar el sistema desde el disco
duro. La partición de swap es una porción del disco duro que permite una ampliación virtual de
memoria RAM cuando la necesidad de esta se ve desbordada por las necesidades de la aplicación
que se ejecuta. La contraprestación que ofrece esta partición es que resulta de acceso mucho más
lento que la memoria RAM, de manera que en la programación se intentará dimensionar el número
de variables de forma que no sea preciso acceder a dicho área de memoria, en favor de la velocidad
de la ejecución. La partición extendida es el tipo usual de particiones, en la que residen datos e
instrucciones generales. No tiene un cometido tan particular como las particiones de arranque y
swap. Será aquí donde se almacene el software y los datos de la computación.
Las particiones /home en el servidor y /home0X en los nodos son las particiones reservadas para
almacenar resultados de los cálculos realizados en la máquina. Estas particiones son exportadas de
cada nodo al servidor y del servidor a todos los nodos mediante el sistema NFS (Network File
System), que será explicado a continuación. El resto de particiones del tipo extendida están
reservadas para almacenar datos del software instalado (sistema operativo, red Scali,...).
Redes internas: Fast Ethernet y Scali
Las redes Fast Ethernet y Scali comunican los nodos y el servidor entre sí. Scali lo hace a mayor
velocidad que Fast Ethernet. Por tanto, Scali será utilizada para las comunicaciones en los cálculos
y la red Fast Ethernet para la comunicación de datos relativos a la configuración de la red, acceso a
19
los nodos, NFS y NIS. La red Scali posee topología de anillo, que consigue disminuir la longitud
del cable de comunicación. Disponiendo de cuatro procesadores, como es el caso del sistema
Vulcano dispuestos de forma alineada, el procesador 1 está unido con el 3, el 3 con el 4, el 4 con el
2 y finalmente el anillo se cierra cuando el 2 se une con el 1.
Network File Sistem (NFS)
Para entender la utilidad de esta manera de comunicar los datos residentes en distintos discos duros
entre sí, es necesario previamente hablar sobre la estructura de almacenamiento de datos del sistema
operativo Linux.
El almacenamiento de datos en dicho sistema operativo se establece a través de una estructura
arbórea, pudiendo dividir la memoria física del disco duro en uno o más árboles, cada uno de ellos
llamado partición. Estas particiones, como ya se comentó, se crean para guardar cierta
independencia entre sí, pero se puede acceder desde cualquiera de ellas a las restantes particiones
del mismo disco duro. En la Figura 3 se muestra un ejemplo con dos discos duros, A y B, cada uno
de ellos dividido en tres particiones. En una disposición así cada disco duro es opaco para el resto,
de manera que no se puede acceder a su contenido a menos que el usuario establezca una
comunicación remota, de forma explícita.
20
Figura 3. Estructura arbórea de los discos duros A y B. E l disco duro A
consta de tres particiones: PA1, PA2 y PA3. El disco duro B consta de otras
tres particiones: PB1, PB2 y PB3.
Un sistema de exportación de archivos de sistema, como es el NFS, permite que particiones
residentes en otros discos duros reciban el mismo tratamiento que las existentes en el disco duro
local de trabajo. Se consigue, que vía este método, se establezca a través de la red que comunica
cada nodo el tráfico de información necesario de manera que a efectos de uso las particiones
residentes en otros discos duros estén consideradas por el disco duro local como propias. Se dice
entonces que dicha partición se ha exportado desde un disco duro a otro. En la Figura 4 se
representa la exportación de la partición PA3 desde el disco duro A al B. El disco duro B entiende
la partición PA3 como propia, aunque físicamente se encuentre externamente a él.
En la instalación de la máquina Vulcano el sistema NFS se ha utilizado para crear una estructura de
datos única que no distinga entre las particiones de datos residentes en un disco duro o en otro. Esta
consideración es muy importante para el trabajo de análisis de los datos resultantes de una
computación. También se exporta mediante NFS desde el servidor a los nodos el software de la red
Scali, que reside en el disco duro del servidor.
Un paso más en la configuración del sistema NFS es la utilización de Autofs. Para que las
particiones exportadas puedan ser accesibles desde cualquier nodo es necesario que exista un tráfico
continuo de información a través de la red que compruebe en cada momento la existencia de dichas
particiones exportadas desde los sitios en que se puede disponer de ellas. Para evitar este tráfico de
información se utiliza Autofs, que permite configurar el NFS de manera que las particiones se
exportan sólo cuando se recurre a ellas, en otro caso no están presentes y la exportación se rompe
transcurrido un tiempo después de haberla utilizado por última vez, hasta que se vuelva a solicitar
su uso.
21
Figura 4. Exportación de particiones por NFS.
Configuración de NIS (Network Information System)
El sistema NIS permite tener una única base de datos en una red interna. En dicha base de datos se
almacenan los datos necesarios de todos los elementos que configuran la red como pueden ser:
claves de acceso, direcciones de acceso de los nodos, etc. El sistema NIS proporciona dichos datos
desde un nodo al resto. Se ha elegido al servidor como nodo donde residen los datos. Esta
aplicación es útil de cara al mantenimiento del sistema, ya que cuando se produce alguna
modificación en el sistema, como la adición o eliminación de algún nodo, es necesario modificar
únicamente una base de datos, la residente en el servidor, que inmediatamente es exportada al resto
de los nodos.
Resultados
Aunque el código no está todavía en una fase madura de desarrollo ha producido unos resultados
muy satisfactorios. La consecución de los objetivos buscados
��robustez y estabilidad de funcionamiento del código.
22
��portabilidad (solo necesita sistema operativo tipo UNIX)
��aprovechamiento efectivo de recursos (posibilidad de correr en los recursos actuales
problemas que no se podían)
suponen una demostración del éxito alcanzado.
Se pueden observar en la tabla comparativa, que se presenta a continuación, los tiempos de
ejecución de una tarea a Re�=950 (archivos de 192 MB) y de una tarea a Re�=1880 (archivos de 1.6
GB) de:
��el programa VORXY serial en uno de los nodos del cluster Vulcano
��el programa VORXY paralelo corrido en Vulcano
��el uso del programa MAESTRO para correr VORXY en Vulcano.
POSTPROCESO DE UN FLUJO TURBULENTO A Re�=950
VORXY-serie VORXY-paralelo MAESTRO-VORXY
56 minutos 15 minutos 19 minutos
Nota: los tiempos presentados corresponden a la media de los tiempos de las tareas corridas.
POSTPROCESO DE UN FLUJO TURBULENTO A Re�=1880
VORXY-serie VORXY-paralelo MAESTRO-VORXY
imposible 2 horas 45 minutos 3 horas 8 minutos
Nota: los tiempos presentados corresponden a la media de los tiempos de las tareas corridas.
Si nos fijamos en la tabla de tiempos para Re�=950, se observa que, como era de esperar, el tiempo
de ejecución para el primer caso es alrededor de cuatro veces mayor que los tiempos de los otros
dos casos en los que se efectúan operaciones en paralelo en los 4 nodos de Vulcano.
23
Más interesante es la comparación entre VORXY paralelo y MAESTRO-VORXY. En estos dos
casos se están usando los 4 nodos de Vulcano, y se comprueba que el tiempo de VORXY paralelo
es algo menor que en MAESTRO-VORXY. Este hecho (previsto) se debe al seguimiento de
subtareas que realiza el programa MAESTRO, que conlleva pérdidas de tiempo por comunicación
entre los nodos.
De esto no se debe concluir que sea mejor correr VORXY-paralelo pues el objetivo principal del
programa MAESTRO no es mejorar los tiempos de ejecución de las tareas, sino poder correr tareas
tan grandes que sean imposibles de realizar de forma VORXY-serie o VORXY-paralelo en
Vulcano.
Esto es lo que pasa a Re�=1880, las tareas (archivos de 1.6 GB) junto a los archivos temporales y
los archivos finales del postproceso que se generan hacen imposible correr VORXY-serie en uno de
los nodos de Vulcano (5 GB para almacenamiento). Al aumentar el Re� en posteriores simulaciones
numéricas, se obtendrán archivos de datos tan grandes (nótese el aumento del archivo de datos al
pasar de Re�=950 a Re�=1880) que VORXY-paralelo será imposible de correr en Vulcano. Es en
estos casos cuando el programa MAESTRO adquiere un papel protagonista.
Los resultados de dicho trabajo han sido presentados en el congreso “Large-Scale Sharing of
Turbulence Data” organizado por la E.T.S.I.A en Junio de 2003
(ftp://torroja.dmt.upm.es/madrid03/delalamo.pdf)
24
Bibliografía
[1] REYNOLDS, O. An experimental investigation of the circumstances which determine whether
the motion of water shall be direct or sinuous, and the law of resistence in parallel chanels. 1883,
Phil. Trans. Royal soc. london 174, 935-982.
[2] HAGEN, G. Über den Einfluss det Temperatur auf die Bewegung des Wassers in Röhren. 1854,
Math. Abh Akad. Wiss. Berlin 17-98.
[3] DARCY, H. Recherches expérimentales relatives au mouvement de 1´eau dans les tuyaux.1857,
Mallet-Banchelier, Paris.
[4] KOLMOGOROV, A.N. The local structure of turbulence in incompressible viscous fluids alt
very large Reynolds numbers. 1941, Dokl. Akad. Nauk. SSSR, 30, 301-305. Reprinted in 1991,
Proc. R. Soc. London. A 434, 9-13.
[5] JIMENEZ, J. Turbulence and vortex dynamics, 2000. Apuntes Polytechnique Touluse, 9-11, 82-
110.
[6] GERMANO, M. Turbulence: the filtering approach, 1992, Journal of Fluids Mechanics, 238,
325-336.
[7] BARDINA, J. FERZIGER, J.H.&ROGALLO, R.S. Effect or rotation on isotropic turbulence:
computation and modelling. 1985, Journal of fluids mechanics, 154, 321-336.
[8] KIM, J., MOIN, P., MOSER, R. Turbulence statistics in fully developed channel flow at low
Reynolds number . 1987, Journal of Fluids Mechanics, 177, 133-166.
[9] ROQUE, C., JIMENEZ, J. Fourier / Chebyshev Methods for the incompressible Navier-Stokes
equations in infinite domains. 1995, Journal of computational physics, bf 121, 261-270.
[10] LAX, P.D., WENDROFF, B. 1960, Comm. Pure Appl. Math. 13, 217-237.
25
[11] MACCORMACK, R.W 1969, AIAA Pap. No. 69-354.
[12] SANJIVA, K.L Compact finite difference schemes with spectral-Like resolution. 1960,
Journal of computational physics, 103, 16-42.
[13] CANUTO, C., HUSSAINI, M.Y., QUARTERONI, A., ZANG, T.A. Spectral methods in fluid
dynamics. 1988, Springer-Verlag 31-60, 65-70, 129-133.
[14] FLETCHER, C.A.J. Computational techniques for fluid dynamics. 1991, Springer-Verlag vol
1, 216-373.
[15] TEMAM, R. Navier-Stokes equations. Theory and numerical analisis. 1977, Nort-Holland.
[16] KIM, J., MOIN, P. Application of a fractional step method to incompressible Navier- Stokes
equations. 1985, Journal of computational physics, 59, 308.
[17] LEE, H., MOIN, P. An improvement of fractional step methods for the incompressible Navier-
Stokes equations. 1991, Journal of computational physics 92, 369-379.
[18] JAMESON, A., SCHMIDT, H., TURKEL, E., Numerical solutions of the Euler equations by
finite volume methods using Runge- Kutta time stepping schemes. 1981, AIAA Pap. No. 81-1259.
[19] LABERT, J.D. Numerical methods for ordinary differential systems.1991, Wiley.
[20] DEL ALAMO, J.C. The large-scale organization of turbulent channels. 2001, Ph. D. Thesis,U.
Politécnica de Madrid.
[21] JIMENEZ, J., PINELLI, A. The autonomous cycle of near wall turbulence. 1990. Journal of
fluids Mechanics, 389, 335-359.
[22] JIMENEZ, J., FLORES, O., GARCIA- VILLALBA, M. The large scale organizations of
autonomous turbulent wall regions. 2002, CTR Ann. Res. Briefs.
26
[23] RICHARDSON, L.F. Atmosferic diffusion shown on a distance nitance nieghbour graph.
1926, Proc. Royal Soc. London, A 110, 709-737.
[24] CHOI, H., MOIN, P. On the space-time characteristics of wall-pressure fluctuations. 1990,
Physics Fluids 2, 1450-1460
[25] http: // www.ccsc.caltech.edu / resource / mixing /index.html
[26] PINELLI, A. El estándar de message passing: MPI. Apuntes del los cursos de doctorado de la
E.T.S.I.A.
[27] WARREN, M., GERMANN, P., LOMHDAHL, P., SALMON, J. Avalon: An alpha/linux
cluster archives 10 gflops for 150k dollars.
[28] SCALI. Scali system Guide, 1999.
[29] SCALI. Scali users Guide, 1999.
[30] STALLINGS, W. organización y arquitectura de computadores. Prentice_Hall, 1996.
[31] I. FOSTER, C. KESSELMAN, J. NICK, S. TUECKE: The Physiology of the Grid: An Open
Grid Services Architecture for Distributed Systems Integration. Open Grid Service Infrastructure
WG, Global Grid Forum, June 22, 2002. (extended version of Grid Services for Distributed System
Integration)
[32] I. FOSTER, C. KESSELMAN, S. TUECKE. The Anatomy of the Grid: Enabling Scalable
Virtual Organizations. International J. Supercomputer Applications, 15(3), 2001.
[33] A. CHERVENAK, I. FOSTER, C. KESSELMAN, C. SALISBURY, S. TUECKE: The Data
Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific
Datasets. . Journal of Network and Computer Applications, 23:187-200, 2001 (based on conference
publication from Proceedings of NetStore Conference 1999).
27
[34] I. FOSTER, C. KESSELMAN: The Globus Project: A Status Report. Proc. IPPS/SPDP '98
Heterogeneous Computing Workshop, pp. 4-18, 1998.
[35] I. FOSTER, C. KESSELMAN, C. LEE, R. LINDELL, K. NAHRSTEDT, A. ROY. A
Distributed Resource Management Architecture that Supports Advance Reservations and Co-
Allocation. Intl Workshop on Quality of Service, 1999.
[36] GLOBUS PROJECT: www.globus.org
[37] GRIDFORUM: www.gridforum.org
[38] SETI@HOME: www.setialhome.ssl.berkeley.edu
[39] LINUX: www.linux.org
[40] LINUX: www.redhat.com
28
